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Abstract 



Formal verification uses a set of languages, tools, and teclmiques to mathematically reason about 
the conectoess of a hardware system. The form of mathematical reasoning is dependent upon the 
hardware system. This thesis concentrates on hardware systems that have a simple determinisdc 
high-level specification but have implementations that exhibit highly nondeterministic behaviors. 
A typical example of such hardware systems are processors. At the high level, the sequencing 
model inherent in processors is the sequential execution model The underlying implementation, 
however, uses features such as nondeterministic interface protocols, instruction pipelines, and mul- 
tiple instniction issue which leads to nondetenninistic behaviors. 

The goal is to develop a methodology with which a designer can show that a circuit ftilfiUs the 
abstract specification of the desired system behavior. The abstract specification describes the Ugh- 
level behavior of the system independent of any timing or implementation details. The natural 
specification of a processor is the instruction set architectme. The specification is defined as a set 
of abstract assertions defining the effect of each operation on the user-visible state. An implemen- 
tation mapping is used to relate abstract states to detailed circuit states. The mapping captures the 
micro-architecture of an implementation of the processor. Symbolic Tiajectoiy Evaluation is osed 
to veriiy that the circuit fulfills each individual abstract assertion under the implementation map- 
ping. Symbolic Trajectory Evaluation can be considered to be a hybrid approach based on sym- 
bolic simuladon and model checking algorithms. 

The methodology has been applied to the fixed point unit of a superscalar processor that imple- 
ments the PowerPC architecture. The processor represents a significant leap of complexity com- 
pared to previous attempts at formal verification of processors. Our approach seems to be the fust 
one that can tmly deal widi the complexity of pipeline interlocks. 
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Chapter 1 
Introduction 

The compJexity of hardware systems has been increasing at a rapid rate. The inttoductioa of Very 
Large Scale Integration (VLSI) techniques has enabled die fiabrication of a significantly larger 
number of transistors on a single chip. A measure of this complexity is the transistor count for sin- 
gle chip processors. Processors have evolved ftom 10"* transistors per chip in 1970 to a projected 
10* transistors per chip in the year 2O00- In an effort to increase performance, modem processors 
use design techniques such as pipelining and parallelism. Tlie resulting interaction between opera- 
tions and the contention for resources creates the potential for Serious design errors. Large design 
teams and critical time to market requirements are two additional factors that complicate the 
design process and introduce "bugs" in hardware systems. 

Simulation is widely used in the industry to validate hardware system designs. Howev^, to exer- 
cise the entire design, an exhaustive simulation requires far too many simulation patterns. This 
point can be made somewhat dramatically by considering the case of a 256-bit RAM circuit The 
RAM circuit has to be validated for 10^0 possible combinations of the initial states and inputs. If 
all the mauer in the galaxy ( 10 ' ^ kg) was used to build computers, and if each computer was the 
size of a single electron ( IQ-^O kg), and if each computer simulates 10^2 ^ases per second, and if 
we began simulation at the time of the big bang (10*^ years ago), then by now we would be just 
0.05% of the way through^! The industry, therefore, has 10 rely on simulating a limited number of 
simulation patterns which typically exercise a small fraction of the circuit This opens the door to 
undetected bugs that could prove to be very costly to the industry. The most recent example is the 
floating point division bug in the Pentium processor[67J. The bug was not detected inspite of 10 
simulation patterns. The bug cost Intel Corporation around $470 million! 



1. This cosmic analysis of ©diaustive simulation lime courtesy of Randy Bryant! 
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An alternative approach that can overcome the weaknesses of simulatioD is fonnal verification. 
Formal verification uses a set of languages, tools, and technique to mathematically reason about 
the hardware system. Hie form of mathematical reasoning that can be used tx> verify a circuit is, to 
a large ejtient, dependent i^on the hardware system. The complexity and vast variety of systems 
has required researchers to develop and explore several different techniques for formal hardware 
verification. 

This diesis concentrates on hardware systems that have a simple detenninistic high-level specifica- 
tion but have implementations which exhibit highly nondetenniiiistic behaviors. Systems that 
operate on an externally visible stored state such as, memories, data paths, and processors often 
exhibit these bdiaviors. The inrq>lementation of these systems fteqaentiy overlaps the execution of 
tasks in an effort to enhance performance while maintaining the appearance of sequential execu- 
tion. At die high level, the sequencing model mlierent in processors is. the sequential execution 
modeL However, the underlying implementations of these processors use features such as pipe- 
lines and multiple instmction issue, which leads to nondeterminism in the implementation. Such 
implementations contain many subtie features with the potential for serious design errors. 

Processors are often implemented as a set of interconnected subsystems. The subsystems have 
complex interfaces and use nondetenninistic protocols to interact with each othen Formal verifica^ 
tion of such subsystems presents a unique set of challenges. The goal is to verify the implmienta- 
tion of a subsystem against the more natural high-level specification of the entire system. The 
verification methodology has to incorporate the ability of defining the environment around the sub- 
systeoL Hie environment defines the set of restrictions and requir^ents placed on the subsystem 
by the rest of the system. The restrictions and requirements are in the form of a set of nondetermin- 
istic protocols defined on the interface signals. In addition to defining these interfaces, the verifica- 
tion metiiodology has to account for complex features such as instruction pipelines, pipeline 
interlocks, multiple instruction issue, multiple cycle instructions, branch prediction, and specula- 
tive execution. 

This thesis outlines a metiiodology for fonnal verification of systems that have a simple and deter- 
ministic high-level specification but have implementations that exhibit highly nondeterministic 

1 
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behaviors[2l]. The methodology is able to bridge the wide gap between the high-level specifica- 
tion and the implementation's often radical deviation from the sequential execution model. A 
methodology for formal verification must ensure that an implementation functions correctly under 
aU possible execution sequences. Since there are an infinite number of execution sequences, we 
verify each operation individually and then reason about sxitching arbitrary operations together to 
form execution sequences^ 

Our methodology uses a technique called Symbolic Trajectory Evaluation (STE) to perform the 
verification task. STE was introduced in the past as a modified form of symbolic simulation to per- 
foaa formal hardware verification[12]. We have extended STE to handle some forms of nondeter- 
minisnL STE can be considered to be a hybrid approach that combines the circuit modeling 
techniques of symbolic simulation with some of the analytic mediods found in model checking 
algorithms. 

Our long-term objective is to use our methodology to verify the Cobra^Lite processor[65]. The 
Cobra- Lite is a superscalar processor that implements the PowerPC architectuie[63]. The proces- 
sor has several complex features such as pipeline interlocks, multiple instruction issue, and out^if- 
order execution. The Cobra-Lite processor represents a significant leap of complexity ftom all pre- 
vious attempts at formal verification of processors, 

1.1 Our Methodology 

The goal is to develop a methodology with which a designer can show that a circuit correctly ful- 
fills an abstract specification of the desired system behavior. The abstract specification describes 
the high-level behavior of the system independent of any timing or implementation details. As an 
Kcample, the natural specification of a processor is the instruction set architecture. The specifica- 
tion is a set of abstract assertions defining the effect of each operation on the user-visible state. 
The verification process must bridge a wide gap between the detailed circuit and the abstract spec- 
ification. In spanning this gap, the verifi^ mu^ account for issues such as system clocking, pipe- 
lines, and interfaces with other subsystems. To bridge tiiis gap between the abstract behavior and 
the circuit, die verification process requires some additional mapping information. The mapping 
defines how the abstract state is reaHzcd in die detailed circuit ITie mapping has both spatial and 

3 
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temporal infojtnatiom As an example, consider an abstract model of a fixed point unit {FXU) Uiat 
receives an opeiand A from an abstract model of the load store unit (LSU), At the circuit level, the 
FXU and LSU use a handshaking protocol with the ready (rdyA) and acknowledge (ac3cA) sig- 
nals as shown in Figure 1.1 . The niapping has to map the abstract signal A into a protocol defined 
on the datA, rdyA, and ac]cA signals. The same mapping can be used to verify both the FXU 
and LSU subsystems. 



Abstract 


_ A ^ 


Abstract 


LSU 




FXU 



Abstract Model 



datA 
rdyA 
ac)cA 



J L 







datA^ 






Circuit 


rdyA ^ 


Circuit 
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_ ackA 


FXU 


1 




' 





Protocol Circuit Model 

Figure 1.1: Mapping abstract signal into an I'nterfoce piotocol. 

Oar specification is thus divided into two components: the abstmct specification and the imple- 
mentation mappins. The distinction serves several purposes. Several feasible ciicuit designs can be 
verified against a single abstract specification. An abstract specification can be used to verify mul- 
tiple implemeniations of the same architecture. Hie abstract specification describes the instruction 
set archilBcture independent of any pipeline details. The task of the mapping is to lelatc the 
abstract specification to the complex temporal behavior and nondeterministic interactions of die 
pipelined implementation. As an example, an instruction might stall in a pipeline stage waiting to 
obtain the necessary resources. The order and timing in which these resources are granted often 
vary, leading to nondeterministic behavior. Our methodology will verify the circuit under all possi- 
ble oidecs and timing. 

The distinction between the abstraa specification and implementation mapping enables hierarchi- 
cal verification. This thesis concentrates on a single level of mapping that maps the abstract speci- 
fication into a specific implementation. In the future, one can envision an entire series of 
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implementation mappings. Each level in the mapping serves to make the assertion more concrete. 
A verification task could be performed at each leve]. A series of mappings could also be used to 
perform modular simulation. Simulation models could be developed at each abstraction level and 
models a: diflfereni levels of abstraction could be intennixed using the mapping information. 

The goal is to verify that the circuit correctly fulfills the abstract specification. In some sense, the 
mapping merely serves as hints to guide the verification task. The abstract specification and the 
implementation mapping are used to generate the trajectory specification. The trajectory specific*- 
tion consists of a set of trajectory assertions. Each abstract assertion gets mapped into a trajectory 
assertion. Symbolic Trajectory Evaluation is used to verify the set of trajectory ass^ons on the 
circuit We use the terms trajectory specification and trajectory assertions partly for historical rea- 
sons. Our trajectory assertions are a generalization of the trajectory assertions introduced by Seger 
and Bryant[18], The justification is that the assertions define a set of trajectories in the circuit 
Informally, a trajectory is a sequence of states that rqiresents an acceptable behavior of the circuit 

Once the abstract assertions have been individuaJly verified, the mediodology must be able to 
stitch operations together in order to reason about execution sequences. The mapping has informa- 
tion about how to stitch operations together. Since the abstract assertions use a sequential execu- 
tion model, stitching operations at the abstraa spccificadon level requires a simple sequencing of 
assertions. The underlying nondeterministic implementation, however, requires operations to 
interact and overlap in time. The mapping allows the user to describe the interactions and oveilap 
between these operations. 

1.2 Specific Details of Our Approach 

Figure 1.2 shows the main components of our strategy for formal verification using Symbolic Tra- 
jectory Evaluation. We have defined languages to describe the abstract specification and the 
ping information. The user provides the abstract specification and the implementation mapping. 
The abstract specification is d^ed as a set of declarative abstract assertions. The mapping lan- 
guage is used to define the relation between the assertions and the circuit. In doing so, it defines the 
interface protocols, the pipeline behavion and the timing for the circuit The Trajeciory Generator 
takes these two descriptions and generates the trajectory specification. TTie trajectory specification 
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is a set of trajectory assertions. The Symbolic Trajectory Evoluaior ts used lo verify the set of tra- 
jectory assertions on the circuit The evaluator can accept gate-level circuit models expressed m a 
subset of Verilog[78] or VHDL[80] languages. We can also verify switch-level circuits[87]. A tool 
called Tranalyzei^Z] can be used to generate an equivalent gate-level representation for a switch- 
level circuit- 
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Symbolic 




Trajectory 
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Circuit 



>- Omputs 




Circuit 



Verified or Countatxample 
Figure 1^: Fonnal vertlkation osing Symbolic I^ecto^ Evaluation. 

The Symbolic Trajectory Evaluator verifies that each individual trajectory assertion holds the 
circuit This implies that each individual abstract assertion holds for the circuit under the imple- 
mentation mapping provided by the user. We, hovrever, want to make the claim that the entire 
abstract specification holds for the circuit under the mapping. The theoretical foundation behind 
our approach supports the claim that verifying each individual abstract assertion amounts to veri- 
fying the entire abstract specificaiioa. And finally, we have to develop a notion of stitching asser- 
tions togetfier to reason about execution sequences. 
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1.3 Application of Our Methodology 

Our long-temi objective is to develop a methodology capable of verifying modern industrial pn>- 
cessoiT!. The touchstone of this work will be the verification of parts of the Cobra^Lite proces-sor, 
Cobra-Lite is a superscalar implementation of the PowerPC architecture[63] used Jn IBM's AS/ 
400 Advanced 36 Computer[64J[65]. Cobra^Lite is an early version of the Cobra processor with 
the processor, cache, and I/O interface on a single chip. It is caUed Cobra-Lite since it is missing 
about 1 7 instructions from the required 64-bit PowerPC set These instnictions arc primarily float- 
ing point instructions that w©re implemented in softwarc. 

There are a number of reasons to pick the Cobra-Lite processor. The Cobra-Lite processor has 
many complicated features found in modem processors such as forwarding logic, instruction pipe- 
lines, pipeUne interlocks, multiple cycle mstmctions, multipJe mstruction issue, conditionally 
issued instructions, and out-of-order execution. Yet the design of the processor is not as aggressive 
as some of the state of the art processors that would completely overwhdm die formal verlfleation 
task. A more practical consid^tion is that the verification of the processor is being done at IBM 
Rochester^ where both documentation and designers arc available to provide a detailed descrip- 
tion of the design. 

A step towards our long-term objective is to verify individual functional units in the Cobra-Lite 
processon This thesis describes the verification of the fixed point unit (EXU). The goal is to verify 
the FXU against the mstruction set specification of the Cobra-Lite processor. Consider an abstract 
FXU that takes in a source operand S and generates the target T, as shown in Figure 13. At the cir- 
cuit level, the FXU interacts with the load store unit (LSU) for the operands. The FXU and LSU 
use a protocol on the interface signals. Our goal is to verify tfic circuit-level view of the FXU 
against the abstract FXU, replacing tiie LSU with an environment model that defines the restric- 
tions and requirements on the intcr6ace signals. 



I . Kyle Nelson, at IBM Rochester, is leading the effort to use our methodology to verify the Cobra-Ute pro- 
cessor. The verification of the Cobra-Lite processor is part of Kyle's PhD work in the Hectrical and Com- 
puter Engineering Department at Carnegie MeUon University. 
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F^ure 13: Sabsystem Terification. 

1,4 Related Work 

There are three main aspects of this thesis: 1- A methodology for formal hardwajt: verification. 
2. Use of SymboUc Trajectojy Evaluation as a verification technique. 3. Applying the methodol- 
ogy to verify tlie PowerPC processor. The next few sections discuss some of the related work in 
each of these areas. More detailed past work has been incorporated ia the relevant chapters. A 
more comprehensive survey of formal verification techniques is available in [l][2], A summary of 
past work and a detailed comparison with our approach will be presented later in Section 1.4,9. 



1.4.1 Foimdation for Our Methodology 

Beatty laid down flxe foundation for our methodology for formal verification of proces- 
sors[13][15]. The instruction set was specified as a set of declarative abstract assertions. A down- 
ward implementation mapping was used to map discrete transitions in the abstract specification 
into overlapping intervals for die circuit The overl^ping was Specified by a nextmarken which 
defined the nominal end of the current instruction and start of the next instruction. Beatty reduced 
the task of verification for all possible execution sequences into a check for three separate proper- 
ties: Ob€dienct\ Conformity, and Distinction- The Obedience property is tiie check to verify tiiat 
individual absti^t assertions hold for the circuit under the implementation mapping. The Confor- 
mity check requires that for every specification input sequence, there should be a corresponding 
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ciraiii input sequence. The Distinction property requires that two distinct output specification 
sequences should have distinct output circuit sequences. Beatty's work, however, had one basic 
limitation. The verification methodology could handle only bounded single behavior sequences. 
Hie mapping language was formulated in terms of a formalism caUed marked strings[13l Marked 
strings could not express divergent or unbounded behavior. 

We have extended the verification methodology to handle a greater level of nondeterministic 
behavior- As a motivating example, consider a fixed point miit of a processor perfonning a bitwise- 
OR operation that fetches two source operands, A and B, from a dual ported load store unit. 
Assume that the fixed point unit and the load store unit use a handshaking protocol as shown in 
Figure 1 . L The fixed point unit may have to wait for an arbitrary number of cycles before either of 
the operands, are available. Furthermore, the operands might be received in different orders: Oper- 
and A cnight arrive before operand B might arrive before A, or both might arrive simultaneously. 
The verification methodology should be able to verify the correctness of the circuit under any 
number of wait cycles and all possible arrival orders. Marked strings cannot expi^ss such an oper- 
ation. Our formulation is in terms of state diagrams that allow users to define unbounded and 
divergent behaviorj 

This thesis concentrates mainly on the Obedience property, i.e., to verify that the abstract specifi- 
cation holds for tiie circuit under some implementation mapping. The conformity and distinction 
properties are discussed as fiiture work. 

Beatty used his verification methodology based on Symbolic 'Lrajectoty Evaluation to vedfy the 
Hector microprocessor[13][15]; Hector is a simple non-pipelined processor similar to the PDP- 
1 1[59][62]. A switch-level implementation of the processor was verified against its instruction set 
architectone. 

1A.2 Model Checking 

Our work has some resemblance to the capabilities provided by model checking tools such as the 
Symbolic Model Verifier (SMV). SMV is a tool fi^r building a finite model of a system and deck- 
ing that a desired property holds in tiiai model[29][30J[3I][33], The SMV input language can be 
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used to define a system as a set of interacting finite state machines. The properties are specified in 
a temporal logic called Computation Tree Logic (CTL). 

SMV requires a dosed system. The environment is modeled as a set of machines. The state dia- 
grams m our mapping allow the user to define an environment aiT>und the system. The state dia- 
grams corresponding to the inputs can be viewed as generators that generate low-level signals 
required for die operation of the processor. State diagrams corresponding to outputs can be viewed 
as acceptors that recognize low-level signals on the outputs of the processor. However, there is one 
essential difference. Though SMV does provide the capability of describing the environment, it 
does not provide a methodology for rigorously defining these machines and stitching them 
together to reason about infinite execution sequences. The other difference is that tiie model check- 
ing algoritiira in SMV requires the complete next-state relation. It would be impossible to obtain 
the entire next-staie relation for a complex processor. We, on the other hand, use STE to evaluate 
tiie next-state fiinction on-the-fly and only for tiiat part of the processor diat is required by tfie 
specification. 

aaike and ofliers used SMV to veri^ die cache coherence protocol described in the tfft: Future- 
bus+ Standard 896.1-I991[34]. The SMV input language was used to create a model of the proto- 
col Model checking was used to verify fliat tiie model satisfied a formal specification of cache 
cohwence describe in CTL. Dill and otiiers used die Murphi verification system to verify die cache 
coherence protix»J of the Scalable Coherent Interface, IEEE Standard 1596-1 992p2]. A model of 
flie protocol was buih based on tiie C code thai is given as a definition of flie Sa standard. Model 
checking was used to verify that the model satisfied a set of properties required for cache coher- 
ence. 

1.4.3 Language Containment 

Kurshan uses language containment to peifoim formal vetification[27][28]. The specification is 
repnssented by a modified form of a deterministic finite state automata called an L-aaionutta. Tbe 
implementation is modeled by a modified form of a nondctermmistic finite state machine called an 
L-pmcess[76\. Kurshan refers to flie specification as a task and to the implementation as a design. 
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Verification is cast in terms of testing whether the formal language X{D) of a design D is con- 
tained in the formal language L{T) of atask 7',i.e., L(D)aL(T) . 

Kurshan uses several techniques to reduce the complexity of the verification problem. The task T 
can be broken into a set of subtasks, where each subtask is represented as a d^emiinjstic L-autom- 
aton. Let i index the set of subtasks. For L-automata, it can be shown that L{T) = r\L{T.) . 
Verifying containment on each individual subtask L(D) c j^iT^) implies containment on the 
entire task J^{D) ^JL{T) , This is similar to our approach. In some sense, the task T corresponds 
to our abstract specification and the individual subtasks correspond to individual abstract asser- 
tions. 

Kurshan also uses reduction transformations as a basis for complexity management The reduction 
transformation is a homomorphism that is defined relative to a task T. The reduction homomor- 
phism can be used to reduce a design D into a sin^jler , and the task T into a corresponding 
T^. Then the containment on die redaced foims X(D^) c £,{T^) implies containment on the 
more complex forms MD)^L(T) . The reduction eliminates ftom the design extraneous or 
redundant details that are tiot relevant to the task T. In our methodology. Symbolic Trajectory 
Evaluation exercises only those parts of the circuit that are relevant to the abstract assertion. 

The reduction transformation can also provide a basis for hierardiical verification. The inverse of 
(he reduction serves as a refinement transfdmation. Assume that and D are the designs at two 
dififerent levels of abstraction hi^aichy, where is the design at the abstract level and D is the 
design at the more concrete level. Then a task verified at the more abstract level would remain 
valid for the more concrete level This thesis concentrates on a single level of the implementation 
mapping. In the future, one can envision an entire series of mappings CO provide a basis for hierar- 
chical verification. In that case, our implemratation mappings would serve the same role as Kurs- 
han's refinement transformations. 

Kurshsin's verification methodology has been incorporated into a tool called COSPAN. The tool 
has been used to formally develop and verify the layered design of communications protocols and 
their implementation in hardware used by several development projects at AT&T and to veriiy an 
arbiter circuit through a four-level hierarchy [2] [25]J 
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1.4.4 Symbolic Simulation 

In the past, ternary simuJation has been used to verify ciicaits[9][]01. Assuming a monotoae exci- 
tation function, the simulation algorithm can ensure that any binary values resulting from simulat- 
ing patterns containing Xs would also result when the X's axe replaced by any combination of O's 
and Ts. Thus ihe nan)b€T of patterns that must be simulated to verify a circuit can often be wJuced 
dramatically by representing many different operating conditions by patterns containing X's, For 
example, terajiry simulation can verify that a particular sequence of actions will yield a binary 
value on some node regardless of the initial state by verifying that this value results when starting 
from an initial state where all nodes are set to X, This requires far less effort than analysing the 
effect of the action on aD possible initial binary states. Ibmary simulation, however, errs on the 
side of pessimism for the sake of efficiency. The simulation will sometimes produce a value X, 
even where exhaustive case analysis would indicate that the value should be binaiy. A reason for 
this pessimism is that the ternary extension of the Boolean operators do not obey the law of 
excluded middle, since + X = where + and - have been extended into the ternary domain. 

Ternary symbolic simulation can be used to overcome some of these limitations(7]. The simulation 
algorithm is extended to operate not just on scalar values 0, 1, and X, but also on a set of symbolic 
values. Each symbolic value indicates the value of a signal for many different operating condi- 
tions, parameterized in terms of a set of symbolic Boolean variables. A single symboUc simulation 
sequence captures multiple ternary scalar simulation sequences. Symbolic simnlation can be used 
to resolve the interdependencies among signal values and avoid the pessimism due to the law of 
excluded middle. The symbolic simulator can compute a + a = 1 , where + and - have been 
extended into the symbolic domain. By combining the expressive pow^ of symbolic values with 
the computational efficiency of ternary values^ we can trade off precision for ease of computation. 

Researchers have used symbolic simulation as a technique for performing formal haidwans verifi- 
cation[3][4][5]. Formal verification based on symbolic simulation can efficientiy model circuit 
behavior with more detailed circuit and timing models. Symbolic simulation is one of the few 
techniques that can model system behavior at a level of timing granularity finer dian complete 
clock cycles. 
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Bose and Fisher used symbolic simulation to verify synchronous pipelined circuits[5]. They used 
an abstraction function to map a pipelined circuit to an abstract nonpipdined version. The abstrac- 
tion function is represented as a circuit, so thai the abstraction function can be evaluated by the 
symbolic simulator. They, hovi^evef. require the user to identify each and every storage location in 
the circuit. They introduced Boolean variables for each input and state variable and computed the 
next-state function for each state variable. It would be impossible to identify all the storage loca- 
tions imd obtain the oexl-state functions for each storage location for systems such as complex 
processors. 

1.4^ Symbolic I^jectory Evaluation 

Symbolic Itajectoiy Evalnatioo (STE) has been used earlier to verify tiajeaory ass^ons. Beatty 
mapped each abstract assertion into a set of symbolic pactcras[ 15], STE was used to verify (he set 
of symbolic patterns on the circuit. The set of symbolic patterns corresponded to single sequence 
of states hi a state diagram. Seger and Bryant extended STE to perform fixed point computations to 
VOTfy a single sequence of states augmented with a limited set of loops[l 8], In our work trajectory 
assertions are general state diagrams. We have extended STE to deal with generalized trajectory 
assertions. 

STE hits been used to verify memory arrays such as on-chip caches and register files. Ptodey and 
others used the VOSS STE system to verify a multi-ported register file unit of a PowerPC proces- 
sor and the tags unit for a data cache circuit from a recent PowerPC design[20]. VOSS is a system 
for fonnal hardware verification that provides a functional language interface to Symbolic Trajec- 
tory Evaluation[141. The number of variables required to verify properties of these arrays was 
approximately logarithmic in the number of memory locations, thus ameliorating fee state explo- 
sion iMX)blem. Pandey and others also used the VOSS system to verify two content addressable 
memories from a recent PowerPC design, a block address translation unit, and a branch target 
address cache unit[22]. New encoding techniques were developed to contam the exponential 
growth in the space requirement with increasing memory sixes. All these dn^uits were modeled at 
the switch level, so that the verification was performed on the actual design- 
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Hazelhurst and Seger have explored a hybrid approach based on theorem-proving and 
STEtl6}[17]- STE is used to prove low-level properties of the circuit A set of inference rules are 
used to compose the results of STE in a theorem proving environment The h^/brid approach was 
able to verify a 64-bit multiplier by verifying the individual adders using STE and then composing 
the results to show that the adders were properly connected[l6j. Aagaard and Seger ased the 
hybrid approach to verify a radix-eight, pipelined, IEEE double-precision floating point multi- 
pliCT[l9]. 

1.4.6 Verificafioii with Uninterpreted Functions 

Burch and Dill have recratly proposed a verification technique to verify pipelined and superscalar 
processor5[46][53]- The user has to provide a behavioral descriptioD of the implementation and 
specification. The specification describes the instruction set architecture of the processor. The 
implementation is described at a level of abstraction that exposes relevant design issues such as 
pipelining. Each of these descripUons is compiled into a ti*ansition function dirough symbolic sim- 
ulation. Let 5" j^^/- and 'I ^^^^ denote the transition functions of the implementation and specifica- 
tion respectively. The correctness criteria is shown in the commutative diagram in Figure 1.4, 
where i? is an abstraction function- The integer m is needed to keep the specification and imple- 
mentation 'In sync". For example, if the instruction does not fetch an instraction due to a lo^ 
inleriock, then m = 0 . For a superscalar processor, m S 1 , Burch and Dill avoid the need to 
explicitiy define the abstraction function. Instead, the abstraction function is implicitly defined by 
flushing the pipeline and then using a projection function to extract only the programmer-visible 
state, i.e., MQi^^i) = '-^9)^^ jiufh^^impl^^ - correctness criteria can now be written as 
^^impl 3'" [^(^ impMimpi^^ = ^sptS^^^impl^^^ " ™" ^^c a quantifier-free firsts 

order logic of uninteipreted functions and predicates with equality and propositional connectives. 
Uninterpreted functions arc used to represent functional units. Propositional connectives and 
equality are used in describing control and comparing the specification and implemaitation. 
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Figure 1.4: Biirch and DiU's comniutative diagram for correctness criteria. 

'We, on the other hand, require the user to define an explicit implementation function j. Hie func- 
tion 3 maps an abstract state into a set of sequences of implementation states. Our correctness cri- 
teria is based on a notion of stimulus and response. Oar correctness criteria is. illustrated in 
Figure 1.5. The initial abstract state is mapped into a set of sequences that serves as the stimulus 
for the circuit- The final abstract state is ms^ped into a set of sequences that defines the desired 
response from die circuit. Hie function ^ jmpl 

is required because STE has to be run for as long as 
specified by the stimulus and response. The implementation function defines a nextmarker which 
IS the tim^>oint where STE needs to start checking the response. The coiiectness criteria can be 
roughly stated as: 

^^^spec^Qspec)^(<'irnpi^^(^,p,c^)l!^I^^^ . where O,^^^ 

represents a sequence of implementation states and the subset property has been extended to 
sequences. 



stimutus 



response 



nextmarker 

F^ure 1^; A aodon of our correctness criteria. 
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Tliere are several other differences between Burch and Dill's approach and our approach. Burch 
and Dill's approach requires a dichotomy between the data path and coniroL They focus on the 
contiol assuming that the data path is correct The user has to provide an abstract description of the 
implementation. On the other hand, we operate directly on the circuit design. And we use Binary 
Decision Diagrams[70], which enable us to verify both th(? data path and control. Furthermore, 
Burch and Dill require that the specification and implementation have the same set of inputs and 
no outputs. In other words, the absliaction function is limited to internal states in the processor. In 
addition to maipping internal states, our implementation mapping allows the user to map an 
abstract input or output at the specification level into a protocol on multiple signals at the imple- 
mentation leveL 

Burch and Dill have used their automated technique to verify a pipelined inq^lementation of a sub- 
set of the DLX architecture[46][51]. The DLX architecture was designed by Hennessy and Patter- 
son to teach the basic concepts used in the MIPS 2000 and other RISC processcH^ of that 
generation[61]. The pipelined implementation was verified against its instruction set architecture. 
Their iTH?lementation had a 5-stage pipeline with a load interlock. The user provided an abstract 
description of the implementation. Subsequently, Burch used the tedmique to verify a superscalar 
implementation of a subset of the DLX pfocessor[53]. To deal with the complexity of the super- 
scaloB* processor, Burch split the commutative diagram into three separate commutative dia- 
grams[53II54]- Their approach, however, has the limitation that the abstraction function can 
become very conmplex in the presence of pipeline interlocks, Burch suggests modifying the proces- 
sor to add a control input that can be used to force the stalling of an instruction at any stage where 
the instruction can be stalled in the pipeline. This, however, requires manual intervention to mod- 
ify the processor and devise a new flushing schedule. 

1.4.7 Theorem Proving and Processor Verification 

Theorem proving has been used in the past to verify nonpipelined processors[40][41][42][43][44]. 
Subsequently, there have been a number of attempts to use theorem proving to verify pipelined 
processors. 
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Srivas and Bickford used the Clio system to verify a pipelined processor called the Mini 
Cay uga[45]. Clio is a functional language-based verification system that verifies properties of pro- 
grams. The programs are written in Caliban, a polymorphic, strongly typed, lazy functional lan- 
guaget37]. The properties to be proved are expressed in the Qio assertion language and proved 
interactively with the Clio theorem prover. The Mini Cayuga is a scaled down version of a RISC 
processor, Cayuga, that was designed in a graduate level VLSI course at Cornell University [60]. 
The Mini Cayuga is a three-stage instruction pipelined processor with a single intOTupt Both the 
specification and the implementation of the microprocessor were specified in Caliban. The correct- 
ness criteria was specified in the Clio assertion language. The correctness criteria was to relate 
traces at the implementarign and specification levels by using an abstraction function provided by 
the user. The verification assumed that the processor started in a known power up state. 

WJndley and Coe used the HOL system to verify a pipelined processor called Uinta[48}i;491. HOL 
is a theorem proving system developed at the University of Cambridge that is based on higher 
order logic[3S]. Uinta has a five-stage pipeline with data and control hazards. The processor uses 
forwarding and delayed branches to deal with these hazards. Wmdley developed the generic 
interpreter theory that provides a standard model for the specification and verification of nonpipe- 
lined processQrs[44l, The generic interpreter theory used two separate abstraction functions, i,e. 
the temporal abstraction function and the data abstraction function to relate the iix^lementation to 
the specification. The temporal and data abstractions, however, are not orthogonal for pipelined 
processors. Windley and Coe used a single abstraction function that intermixed the data and tem- 
poral Jibstractions to verify the Uinta processor. They used case analysis to deal with pipeline stalls 
and were able to limit the proof to one stall case split by using a lemma to show that the pipeline 
cannot stall twice in a row. 

Researchers have used the Prototype Verification System to verify a number of pipelined proces- 
sors[47][52]I55]- The Prototype Verification System (PVS) is an enviromnent for specification and 
verification that has been developed at SRI[38]. PVS combines a highly expressive specification 
language based on higher order logic, with a very effective interactive theorem prover in whidl 
most of the low-level iwx>of steps are automated. 
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Cyrluk and others used PVS to verify the Saxe pipelined pfocessor[47] and Burch and Dill's pipe- 
lined DLX processor[55]. The specification and implementation were specified as state transition 
systems. The correctness criteria related traces at both levels by using an abstraction function pro- 
vided by the user. Tb& limitation is that the user has to provide the number of cycles that it takes 
the implementation to complete an instiuccion as a function of the current state and future instruc- 
tions. However, for modem processors, the number of cycles for completing an instruction might 
be indefinite due to pipeline interlocks or stalls. 

Srivas and NiOUer have used PVS to verify the AAMP5 microprocessor[52]. The AAMP5 belongs 
to a £amily of Rockwell proprietary microprocessors based on the Collins Adaptive Processor Sys- 
tem[S8]. The AAMP5 has a large complex instruction set, multiple data types and addressing 
modes, and a microcoded, pipelined implementation. The implementation of the AAMP5 has 
some SOOfOOO transistors. A factor complicating the verification of the AAMP5 is that it can stall 
for an arbitrary number of cycles due to memory wait states and stack adjustments. Srivas and 
Miller decomposed the verification problem into three sub-problems: 1- A part that reasons exclu- 
sively abom tlie stalUng behavior. 2. A part that reasons about individual instructions in the 
absence of stalling. 3. A part that combines tiie first two parts. The coiTCctness of pipeline stalling 
was characterized by a set of formulas called general verification conditions since they are com- 
mon to all insi ructions. The correctness of individual instructions in the absence of stalling was 
characterized by a set of instruction-specific verification conditions. Srivas and Miller comment on 
tiie difficulty of verifying the general verification problems as follows: Since the general verifi- 
cation conditions are not in the form of a property that relates states that are a finite distance 
apart, their proof is not as automatic as that of the instruction-specific verification conditions. The 
proof involves Induction on the length of time taken by the memory to respond or site of the stack 
adjustment needed and requires involvement by an expert/' Srivas and Miller needed to formulate 
only a few general verification conditions since the AAMP5 has only three stalling sitoatioos and 
all of these are instruction independent On the other hand, Cobra-Lite has raudi more complex 
stalling situations that are dependent on the instructions (or at least the instruction formats). 

Researchers have used the ACL2 theorem prover to verify pipelined processors[56}[57]- ACL2 
stands for 'A Computational Logic for Applicative Common Lisp." ACL2 is both a mathematical 
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logic aad a set of tools which can be used to construct proofs in the logic[36][39]. The logic is a 
quaniifier-firee first-order logic of total recursive functions. 

Brock and others used the ACL2 theorem prover to verify the CAP processor[56], CAP is a DSP 
co-processor optimized for communications signal processing under development by Motor- 
olaI66]. CAP has a three-stage instruction pipeline and does not have any control logic to deal witfi 
pipeline hazards. It is the task of the programmer to avoid pipeline hazards in their DSP applica- 
tion code. Brock used the same approach as Burch and Dill, thus avoiding the need to define an 
explicit abstraction fimction. ACL2 did not have to deal with the complexity of pipeline interlocks 
since the verification was performed on only hazard-free code. It should, however, be acknowl- 
edged that depending on the verification strategy^ compiler assumptions can be more difficult to 
handle than pipeline interlocks. 

Sawada and Hunt used the ACL2 theorem prover to verify an out-of-order pipelined proces- 
sor[57]. They designed their own processor The processor includes out-of-order execution and 
speculative instruction fetch. In ordex to avoid pipeline hazards^ the issuing logic suspends the 
issue of any instruction which may cause a hazard. Once an instruction is issued, it is guaranteed 
that no hazard will occur due to the instruction. Sawada and Hunt use the same approach as Burch 
and Dili, avoiding the need to define an explicit abstraction function. They use a table to store an 
execution trace of instructions representing states in the implementation. The table representation 
helps to easily define various pipeline properties, such as the absence of WAW-hazards. In a sense, 
the table captures the past history of the processor. In Symbolic Trajectory Evaluation, the initial 
state of the circuit is set to the most general state that reflects all possible past histories for the pro- 
cessor. 

1.4.8 Miscellaneous 

All of the past work mentioned so far concentrated on comparing the instruction set architecture 
with an implementation of the processor. Some researchers have used combinational equivalence 
checking to coiiq)aie the RTL, gate or transistor level representations of a processor. Appenzeller 
and Kuehlmann used Verity to verify the PowerPC microprocessor{50]. Verity is a verification tool 
developed at IBM for functional verification of large transistor and gate-level circuits by using 
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Binary Decision Diagrams. Appenzeller and Kuehlmann compared an implementation at the regis- 
ter tiansfer-level with the transistor-level implementatioT>- The user had to identify the storage 
locations in both representations and Venty was used lo perform combinational verification, 

1.4.9 Summary of Past Work 

Most of the past work in formal verification of pipelined processors has concentrated on relatively 
simple processors. Some of the limitations of previous wort: and their relation to our strategy for 
verifying the Cobra-Lite processor are as follows: 

• Most of the past work required the user to provide some abstracted version of the processor 
implementation. Either the datapath had to be abstracted away or Che user bad to give a cycle 
level transition function for the implementatioa. Symbolic Trajectory Evaluation enables us to 
verify an actual gate-level circuit design of the Cobra-Lite processor The use of Binary Deci- 
sion Diagrams enable us to verify both the data path and control simultaneously. 

• Past work has been limited to processors with very simple implerhentations. The Cobra-Lite 
processors is a real design that is significantly more complex both in terms of the size and fea- 
tures incoipoxaied in the implementation. It is doubtful whether any of the existing techniques 
would be able to verify the entire processor as a single entity. The Cobra-Lite processor is 
designed as a set of interconnected subsystems or functional units. We are advocating decom- 
posing the problem of verification of the entire processor into smaller subproblems of verifica- 
tion of individual functional units. We would like to verify each individual functional unit 
against the instruction set architecture of the entire processor and then reason about the interac- 
tions betwe^ various functional units. This thesis is the first step in this darection and concoa- 
trates mainly on subsystem verification. 

• AH the previous verification techniques assumed that the specification and the implementation 
had the same set of inputs and outputs. The abstraction function related only internal states hi 
the specification and implementation. In other words, the correctness criteria actually compared 
the pipelined processor with a nonpipelined version of the processor. These techniques are not 
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suitable for subsystem verification. Oar implementation mapping maps abstract inputs and out- 
puts into protocols at the lower level. A major part of our work is to provide a methodology for 
rigorously defining the enviromnent around the functional unit to be verified. 

• Past work has dealt with simple pipeline interlocks. Most of the past work were able to limit the 
verification to a single cycle pipeline interlock. It is conceivable that the verification could be 
extended to pipeline interlocks for an indefinite number of cycles. However, the previous 
approaches have not clearly shown that this can be done without significantly increasing the 
complexity of the verification task. The functional units in the Cobra-Lice processor have com- 
plicated control logic to deal with pipeline interlocks. There are a numb^ of reasons for an 
instruction to stall for an indefinite number of cycles in a pipeline stage. Our verification has to 
prove the correcmess of the functional units under all possible scenarios and under all possible 
number of stall cycles. 

It is worthwhile to compare various different approaches to processor verification as regards the 
degree of automation and robustness to minor modifications in the implementation. We are 
attempting to use automated techniques to verify a real processor. It should, however, be acknowl- 
edged that comparisons between automated and manual techniques are very subtle. Our approach 
is probably more automated than some of the theorem proving efforts which require considerable 
human guidance to perform the verification. However, our approach requires an up-front manual 
effort to provide the implementation mappuig. The implementation noapping can become quite 
complex and requires an understanding of several low-level details in the gate-level implementa- 
tion of the processor. Bunch and Dill's approach can be considered to be more automated since 
they avoid the need to exphcitly define an abstraction funcdon. The abstraction function is implic- 
itly defined by flushing the pipeline and then using a projection function to extract only the pro- 
grammer-visible state. The problem is that they have to modify the processor and devise a new 
flushing schedule to limit the complexity of the abstraction fimction. 

Another point of comparison is the robustness of diff^ent approaches with respect to minor modi- 
fications in the implementation. Some theorem proving efforts require the user to define both an 
abstracted version of the implementation and the abstraction function. These theorem proving 
efforts are the least robust since they could require redefining both the implementation and the 
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abstracition function. The comparison between our approach and Burch and Dili's approach is not 
so clear. Our approach would not require any effort to redefine the implementation, since we oper- 
ate directly on the gate-level implementation. The implementation mapping, however, might have 
to be ledefinecl. Burch and Dill do not require the user to provide the abstraction function. The 
implementatioJi* however, might have to be recompiled into a transition function. Also, the user 
might have to define a new flushing schedule for the modified processor. 

1.5 Limitations of our Work 

It is worthwhile to discuss some of the limitations of our approach. Here, we will briefly state the 
major limitations of our approach. Several techniques to deal with some of these limitations are 
discussed as future work in Chapcer 9- 

• Our approach is targeted towards verification of systenns that have a simple and deterministic 
high-level specification but whose implementations can exhibit a variety of possible nondeccr- 
ministic beliaviors. Processors^ memories and data paths are an example of such class of sys- 
tems. However, we cannot verify systems, such as a cache coherence protocol, that do not have 
a simple high-level specification. 

• A major limitation is that Symbolic Trajectory Evaluation requires a deterministic circuit-level 
model of the implementation. Let us assume that we are attempting to verify a system of multi- 
ple interacting finite-state machines. Our approach would require a detailed low-level model of 
all these machines and verify th^ as one single entity. It is not possible to verify each individ- 
ual finite-sfcite machine atid then reason about their interaction at some abstract level. 

• The user is required to provide the implementation mapping. As stated before, the implementa- 
tion mapping can become complex and requires a detailed understanding of the circuit 

• Our approach does not scale well for more complex processors. The trajectory generation phase 
generates all possible nondeterministic behaviors in the subsystenL Increasing the pipeline 
depth or the number of resources in a subsystem can lead to an exponential blowup in the num- 
ber of possible riondeterministic behaviors. The methodology has been used to verify the fixed 
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point unit of the CobrarUte processor. The fixed point unit has a shallow three-stage pipeline. 
Several modifications and enhancements would be required to deal with processors with deeper 
pipelines and superscalar execution, 

* Symbolic Trajectory Evaluadon uses Binary Decision Diagrams to verify both the data path 
and control simultaneously. Our approach, therefore, suffers from the typical limitations associ- 
ated with Binary Decision Diagrams. Careful attention has to be paid to the variable Mdeiing to 
limit the size of the Binary Decision Diagrams. 

1.6 Overview of the Thesis 

The essential ingredients of our formal verification methodology can be described as: 1. The lan- 
guages defining the abstract specification and the implementation mapping. 2. The trajectory gen- 
eration phase, 3. The verification algcwithm Oncluding Symbolic Trajectoiy Evaluation). 4. The 
theory that puts it all together. The thesis foUows this order, 

Chapttn: 2 explores various notations for expressing abstract specifications. Hardware Description 
Languages are not suitable for spectfytng hardware. This chapter introduces a HarAvare Specifica- 
tion Language to specify hardware. The basic form of the Hardware Specification Language 
defines a nondeterministic Moore machine. The transitions in this machine are defined as a set of 
declarative abstract assertions. The chapter describes symbolic and vector ext^asions for the lan- 
guage to ease the task of writing specifications. The syntax of the language is shown with exam- 
ples. 

Chapter 3 introduces the form of the implementation mapping. The implementation mc^ping is 
defined in terms of a variation of state diagrams called control graphs. The basic form of the 
implementation mapping consists of a main machine and a set of map machines. The main 
machine defines the flow of control of individual system operations. The map machines define a 
spatial and temporal mapping for each abstract state in the specification. The chapter describes 
symbolic and vector extensions to ease the task of writing the mapping. The syntax of the mapping 
language is shown with examples. 
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Chapter 4 describes the trajectory generation phase. The abstract specification aDd mapping are 
used to generate the trajectory specification. Each abstract assertion gels mapped into a trajectory 
assertion. The main step in trajectory gen^tion is the composition of control graphs. This chapter 
describes the composition operator in detail- The main elements of the trajectory generation phase 
are illustrated with a simple example. 

Chapter 5 describes various verification algorithms that could be used to verify the set of trajectory 
assertions on the circuit This chapter introduces the term Trajectory Checking. The term trajectory 
checkitjg has been coined to denote its mixed heritage from model checking and Symbolic Trajec- 
tory Evaluation, Trajectory checking uses a relaxation algorithm to label the trajectory assertion 
with circuit states. There are two fomns of trajectory checking, Le., a set-based and a lattice-based 
approach. The lattice-based c^pioach can be viewed as an approximation of the set-based 
approach. Symbolic Trajectory Evaluation can now be viewed as a technique to overcome the lim- 
itations of trajectory checking. The trajectory checking algorithm requires the entire next-stare 
function for the circuit. SymboHc Tr^ectory Evaluation enables the next-state function to be com- 
puted oQ-the-fly and only for that part of the circuit required by the specification. The cluster dis- 
cusses extensions to Symbolic Trajectory Evaluation to deal with our generalized model of 
trajectory assertions. 

Chapter 6 is where we put it all together. This chapter revisits some of the concepts introduced in 
earlier chapters and develops a firm theoretical foundation for formal hardware verification using 
SymboHc Trajectory Evaluation. The previous chapter verified that each individual abstract asser- 
tion holds for the circuit under the mapping. The theoretical foundation behind our approach sup- 
ports the claim that the entire abstract specification holds for the circuit under the mapping. 

Chapter 7 describes some preliminary work in reasoning about execution sequences. This chapter 
introduces the concept of closure construction as a means of stitching operations or assertions 
together to form infinite execution sequences. 

Chapter 8 applies our methodology to verify the fixed point unit of a superscalar implementation 
of the PowerPC architecture. The chaptCT gives an overview of the fixed point unit, and describes 
details of the abstract assertion and the implementation mapping that were used to verify the fixed 
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point unit The chapter describes the result of irajectory generation and Symbolic Trajectory Eval- 
uation. 

Finally, Chapter 9 has a discussion of future work and conclusions- 
Appendices A and B contain the man pages describing the syntax of the Hardware Specification 
Language and the inr^lementadon mapping. 
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Chapter 2 

Abstract Specification 

This cliapler expires notations for expressing abstract specifications. Any specification notation 
should be both simple and abstract, providing designers with a natural way to specify hardware. 
On the other hand, it should allow designers to specify low-level details that are relevant to the 
design task. Though this thesis concentrates on formal verification, a specification notation has to 
suppon other CAD tasks such as simulation and high-level synthesis. A high-level simulation task 
allows the user to informally check the validity of the specification. A specification can be mapped 
into concrete circuit realization jn a variety of different ways. At one end of the spectrum is a com- 
pletely manual custom designed circujL At the other end is a completely automated high-level syn- 
thesis task. After obtaining a realization, one has to verify that the circuit fulfills the specification. 
There iue several CAD tasks that can be used to pttfonn this verification. Simulation can be used 
to estatilish a degree of confidence in the circuit F(^mal verification can be used to mathematically 
reason about the correctness of a circuit with respect to a specification. A specification notation 
has to serve the needs of all the above mentioned CAD tasks. 

High-level behavioral constructs in Hardware Description Languages (HDLs) seem to be the obvi- 
ous choice for this notation. Designers are ^miliar with HDLs and they have been used exten- 
sively In the past for simulating and reasoning about high-level descriptions. However, HDLs tend 
to overspecify systems, since they tend to describe a sample implementation rather than an abstract 
specification. Hardware Description Languages are useful languages for describing hardware. 
However, they are not suitable for specifying hardware. We introduce a Hardware Specification 
Language to specify hardware. 

2.1 Hardware Description Languages 

Hardware Description Languages have been widely used to describe systems at varying levels of 
abstraction. Some of the more popular Hardware Description Languages in tlie market are Ver- 
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ilog|78]» VHDL[80], and UDL/1[79]. The behavioral constructs in these languages can be used for 
specifications- Typically HDLs also offer stnictural constructs to describe low-level rea]l2ations. 
Therefore, they provide a single framev^rork for describing both the specification and ciicuit 
design. Designers have been using HDLs extensively to model systems. Commercial simulators 
are available to simulate most HDL descriptions at all degrees of abstraction. In recent years, there 
have been several attempts to use an HDL subset as the front end for high-level synthe- 
sis[81][82]t83][84l. Therefore it seems that all that has to be done is to adopt HDLs as a specifica- 
tion notation for formal verification. 

The first problem with HDLs such as Verilog and VHDL is that they lack formal semantics. 
Recently, there have been some attenipts to define formal semantics for at least a subset of 
VHDL[77I. Furthennore, UDL/I has a documented formal semajitic[79]. For the moment, 1^'s 
assume that formal semantics have been defined for these HDLs. Let us adopt Verilog HDL as our 
specification notation and attempt to specify the high-level behavior of a stack. 

Consider a realization of a stack where each element in the stack is moved down on a push opera- 
tion and each element is moved up on a pop operadon. Such a stack is called a Moving Data StacL 
Let*s write a specification for such a stack using Verilog HDL. Such a specification is shown in 
Figure 2.1. All timing has been abstracted out by assuming a positive edge triggered stack, 
although this jntrodoced an explicit clock as an implementation arti£ict. The essential component 
of the specification is the always block. The always block is activated at all positive edges of the 
clock, causing a push or pop operation to be performed on the control signal op. This example 
shows several whcstcomings of the specification. Note that the iterations (for loops) have to be 
carefully set so as to shift the bottom elements first during a push operation and the top element 
first during a pop operation. In a push operation, the data input is stored in the stack only after 
shifting all elements in the stack. In the pop operation, the output is set before shifting all elements 
in the stack. In other words sequencing of operations becomes a major issue in these behavioral 
descriptions^. Furthennore note that the hold operation is not explicitly specified. The semantics 
imposed by a simulator on these languages is that if no action is specified, then the signals retain 

1 . It should be acknowledged that sorjie of the sequencing issues can be dealt with use of non-blocking 
assignments. 
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their previous values. The semantics implicitly incorporates the hold operation. Note thai the 
semantics impose the same functionality on the illegal (op = 2*bll) operation. In a circuit, the 
environment around the stack might ensure that op is never set to 2'bll. In diat case the illegal 
operation is a don't care condition for the stack. Imposing the hold functionality to the illegal oper- 
ation is overspecifying the stack. Finally^ let's take a look at the boundary conditions for the stack. 
According to the behavioral description, a push on a full stack discards the bottom-most clement in 
the stack and inserts the data input into the top of stack. A pop on an empty stack sets the data out- 
put to the value stored on the top of stack. The value on the top of stack is dependent on the past 
history of operations on the stack. If in the past the stack has never been iilled to capacity, then this 
value is the initialized value for the top of stack. Howevw, if in the past the stack has been filled to 
capacity, then the value is the element that was stored at the bottom of the stack. 

module MovingDataStackSpec(dataOut. datafn, op, dock) 
output dataOut; 

input [0:1] op: // Push=2'b00, Pop=2'b01, Hold=2'b10. IIIegal=2'b1 1 
input datatn; 
Input dock: 

reg[0:1 023] Mstack; // Defining a moving stack of 1024 elements. 

reg dataOut; 

regi; 

always @(posedge dock) 
begin 

If (op =^ 2*600) // Push Operation, 
begin 

for (1 1023; i > 0; i = i - 1) Mstackp] = Mstackp-1]; 
Mstackfoj^dataln: 
end 

if (op = 2^01 ) // Pop Operation, 
b^tn 

dataOut = Mstack[0]; 

for (i = 0; i < 1023; r = i + 1) Mstackp] = MstackO+IJ: 
end 
end 
endmodule 

Figure 2.1; A Verilog HDL specification of a moving data stadc 



One of the goals in verification is thai a single Specification should be able to check several possi- 
ble circuit designs. Towards that end, let us consider another realization of the stack. This realiza- 
tion is a Stationary Data Stack based on a RAM and a top of stack pointer. The pointer points to 
the first free location in the stack. Unfortunately, the moving data stack specification cannot serve 
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as a specification for the stationary stack, A Verilog HDL behavioraJ description for a stationary 
stack is shown in Figure 2.2. The top of stack tos is a 10-bit register, which can store integers in 
the range 0 to 1023, Note thai tos points to location 1023 when the stack has 1023 elements. A 
subsequent push operation attempts to increment tos beyond its range. The lack of formal seman- 
tics implies that the tasks are free to choose their own semantics for this increment Unfortunately, 
different tasks might assign different semantics. This is clearly undesirable since the tasks do not 
have a consistent interpretation of the specification. However, assume for the moment that an s 
sized register defines a modulo s arithmetic (this is the semantics imposed by the Cadence Verilog- 
XL simulator.). In that case tos will point to location 0 for a full stack. Such a wraparound stack 
cannot distinguish between a full and empty stack. 

module Stationary DataSpec(dataOut dataln. op. clock) 
output dalaOut; 

Input [0:t] op; // PushsaiaOO, Pop=2'b01 . Hold=2'b10, inesal=2'b1 1 
input dataln; 
input clock; 

reg [0: 1 023] S$tack; // Defining a stack of 1 024 elements, 
reg dataOut; 

reg [0:9] to3; // 1 0 bit top of stack pointer. 

initial tos = 0; 

always @(posedge clock) 
begin 

If (op = 2'bOO) // Push Operation, 
begin 

Sstackttos} = dataln; 

t03=t03 + 1; 

end 

H (op == 2'b01) // Pop Operation, 
begin 

tos =1 tos - 1 ; 
dataOut = Sstack[t05]; 
end 
end 
endmodule 

Ftgnrc 2^: A Verilog HDL spedfkatlw of a stationary data stack. 



Note that the two stack specifications define different boundary conditions. To illustrate the difiBer- 
ence assiune that both stacks are full with a logic 0 stored at the bottom of the each stack and logic 
1 stored at all other locations. Now empty both stacks by performing 1024 pop operations. The 
input/output behavior for these 1 024 operations will be the same for both Specifications. At the end 
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of the pop operations, however, the interoal state of the two stacks axe differenu The internal state 
of the stationary stack is exactly the same as before. The moving data stack, however, now has a 
logic 0 stored in each location of the staclc Two subsequent pop operations from the empty stack 
will reflect this difference in the input/output behavior of the stacks. The problem again is that the 
Stacks have been overspecified. The details of the boundary conditions might differ from one real- 
ization to the other. Unless the designer requires a specific way of handling these boundary condi- 
tions, they should not be specified* 

0 1 

X 

Figure 23: Partial order defined on logk Oyl^L 

It should be acknowledged that overspecification is not an inherent limitation of these HDLs. It is 
possible to strictly specijfy a stack through a judicious use of the X logic value. In this model, the 
logic value X is assumed to imply less information than the logic 0 and logic 1 values as shown in 
Figure 23. The operations used in the specification have to be monotonic in the foUowing sense: If 
an opcratioD evaluates to a 0 or 1 in the presence of some X's^ then the operation should evaluate to 
the sajne value even if any number of X's are replaced by any combination of O's and I's. Under 
this monotonicity constraint, the stationary stack can be strictly specified as shown in Figure 2.4. 
The registers have been set to X for the boundary conditions and the illegal operation. The tasks 
are free to interpret X as either 0 or 1. Hie irony in such a description is that the designer had to 
give Ciiiefiil consideration to those aspects that contribute the least to the functionality of the stack* 
Le. the boundary conditions and the illegal operation. It can be seen that this description is much 
more complex and cumbersome compared to the simple stationary stack speciBcation in 
Rgure 2.2. Loops had to be introduced in the description. Only upon a careful analysis does one 
realize that this description specifies a stationary siack-| 
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module SlrictlySpecifiedSlationaryDataStackSpec(dataOut. dalain, op. clock); 
output dataOut; 

Input [0;l ] op; // Push=2'b00, Pop=2'b01 . Ho!d=2'b1 0, lIlegaNa'bl 1 
input dataln: 
input clock; 

reg [0:1 023] Sstack; // Defining a stationary stack of 1 024 elements, 
reg dalaOut; 

reg [0:1 0] tos; // 1 1 bit top of stack pointer, 
integer j; 

initial tos = 0; 

always @(posedge dock) 
begin 

it (op = 2'bOO) // Push Operation, 
begin 

if (tos < 1024) 

Sstack[tos] = dataln; tos = tos -i- 1 ; 
end 

else begin // Push on a full stack is not defined. 

for (i = 0: i < 1024; i « i + 1) Sstackp] = n^x; 

tos = 1l'bx: 
end 

dataOuts Vbx: 
end 

if{op = 2'b01) // Pop operation, 
begin 

H (tos > 0) 

tos o tos - 1 : dataOut = Sstackjtos}; 
end 

else begin // Pop from an empty stack is not defined. 

for (i = 0; i < 1024; i s i + 1) Sstack[i] =i Vbx; 

tos = 11'bx; 

dataOut= Vbx; 
end 
end 

// Hold operation implicttly defined by the semantk;s- 

H (op = 2'bi 1 ) // Ulegal operation, 
begin 

for (i = 0; i < 1024; i = i + 1) Sstack[i] = Vbx; 
tos = i1'bx; 
dataOiJt=ri'bx; 
end 

endmodule 

Figure 2.4: A strictly qpcdfied Verilog i£DL description of a stationaiy dat^ stacls. 
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In sumniaiy, Hardware Description Languages are not ideal as a specification notation for formal 
venflc'ition due to the following reasons: 

• Realization Dependent: Probably the most important limitation is that low-level implementa- 
tion details creep into the high-level behavioral HDL specification. This makes it extremely dif- 
ficult to write a specification which is independent of the realization. The need for a 
specification language to be independent of the reaJixaoon has been referred to as the Neutrality 
piOperty[76], 

• Simulation Specific: HDLs are very simulation specific. All these languages were originally 
developed to allow users to construct simulation modelsu Hence, they contain features that are 
based strongly on the execution mode! provided by event-driven simulators, 

• Sequencing: A designer has to give caxefiil consideration to sequencing of operations while 
writing HDL descriptions. Hiis might be overkill since the verification cask is usually con- 
cerned only with the end result of a set of operations. 

• OverSpedfication: Designers normally tend to overspecify their systems. The lack of don't 
care information results in false negative reports by the formal verification task. The false nega- 
tive reports are due to the verifier labeling a correa design as defective. A stack might be 
reported to be defective due to different boundary conditions or a difTerent response to an ille- 
gal operation. 

• Formal Semantics: Most HDLs do not have well-defined formal semantics. Even though 
UDL/I has documented formal semantics, the semantics are defined in terms of an event-driven 
scheme, which takes us back to the point that HDLs are very simulation specific. 

It seems that Hardware Description Languages are appropriately named. They ate languages for 
describing hardware. However, they are not appropriate for specifying hardware. In this thesis^ we 
introduce a Hardware Specification Language to specify hardware. 

2.2 Related Work 

Our Hardware Specification Language is based on the State Machine Assertion Language (SMAL) 
introduced by Beatty[iaj. SMAL is a declarative language widi a documented denotational 
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semantics. The language describes each operation as ai) assertion. The assertion consists of a pre- 
condition describing the set of abstract states at the start of the operation and a postcondition 
describing the set of abstract states at the end of the operation, SMAL was used to describe a par- 
tial specification of the Hector micfoprocessor(59]. 

23 Basic Form of Hardware Specification Language 

This section defines the basic form of the Hardware Sp«;ificatjon Language. The exact syntax of 
the language will be described in later sections. The basic form is quite simple. It might seem that 
this basic form can only be used to specify trivial behaviors. Later on, however, we will extend the 
language into the symbolic and multivalued domains and give several examples of how ncmtrivial 
behavior can be spediied using this language. 

The abstract specification is associated with a set of single-bit abstract elements, . Abstract ele- 
ments collectively refer to inputs, outputs, and stare elements in the abstract model. The effect of 
each operation is defined as an abstract assertion. Each abstzact assertion is of the form: P^Q^ 
which should be read as the precondition P leads to the postcondition Q. There is an implicit ' 
notion of passage of time from the precondition to the postcondition- P and Q are abstract formur 
las oftlieform: 

• Simide abstract formula: {s^ is 0) and {s- is 1) are abstmct formulas if b ^ 

• Coiyiinction: (FjandF2) is an abstract formula if Fj andF2 are abstract formulas, 

• Domain Restriction: (0 F) and ( 1 — ^ F) are abstract formulas if F is an abstract formula. 

In addition, we will let true r^resent the trivially true abstract formula. The domain restriction 
appears at first somewhat strange. The usefulness will become apparent when we extend the 
abstract formulas to a symbolic doniain. 

Each abstract assertion defines a set of transitions in an abstract Moore machine. The semantics of 
an abstract assertion can be defined as follows: If the abstract machine starts in a set of states that 
satisfy the precondition, then the machine should transition into a set of states that sadsfy the post- 
condition. Else, if the machine starts in a set of states that does not satisfy the precondition* then 
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the assertion does not place any restrictions on the set of transitions. The intersection of all asser- 
tions defines a nondetennirustic Moore machine. In this sense, the abstract specifications are theo- 
retically being rq?resenied as Moote machines. The assertions are simply a convenient way to 
describe the set of transitions of this machine. 

Consider the example of an inverter. An inverter requires two abstract elements. In and Out, 
where In corresponds to the input of the inverter and Out corresponds to the output of the 
invertei-. The inverter can be spccitied using 2 abstract assertions: 

(InisO)^(Out is 1) // Assertion 

( In is 1 ) ^ {Out is 0) // Assertion A2 

Mathematically, ian abstract assertion can be defined as follows: Assume 5 is the set of assign- 
ments to the abstract elements, 5 = {0, 1 }" , where n = . Define a satisfying set for an 
abstract foimula as the set of assignments that satisfy the atetract formula. The satisfying set of an 
absiraci formula written Jat(F) , is defined recursively: 

• Sat{true) = S - 

• Satis ^ is 0) is the subset of S containing 2" " ' assignments having the i * position as 0, Sim- 
ilarly Sat{s*ls 1) is the subset of S containing 2""^ assignments having the position 
as 1. 

• SatiFj and Fj) = Sat(F^) r^SatiFj) . 

• SatiO-^F) = S,and Jat(l SatiF) 4 

For an abstract assertion A = ^ the sets SatiP) and SatiQ) are the set of assignments 
that satisfy the precondition and postcondition respectively. The transitions associated with the 
assertion can now be defined as: TrasisiA) = [Sat{P)xSat{Q)]LJ[{S'' Sat{P))xS} . 
Renrieniber if the abstract machine starts in a s^ of states that satisfies the precondition* then the 
machine should transition into a set of states that satisfies the postcondition. The set 
5at{P) X SatiQ) represents the set of transitions when the precondition is satisfied. If the 
machine starts in a set of states tJiai does not satisfy the precondition, then the assertion does ncrt 
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place aoy restrictions on the scl of transitions. The set {S-Sat{P))xS represents the set of 
transitions when the precondition is not satisfied. 

Let i index the set of abstract assertions. The intersection r^TransiA^ defines a nondeterminis- 
tic Moore macliine corresponding to the abstract specification. 

For the inverter example, n = 2 and the set 5 has 4 state assignments, S = {00, 01, 10, 1 1 ) , 
where the left bit is the logic value associated with In and the right bit is the logic value associated 
with Out. The transitions corresponding to these assertions are shown in Figure 2.5. Let us con- 
sider assertion A^. Now 5flt(Inis0) = {00,01} and 5ai(Outisl) « {01.11) .The solid 
edges represent transitions when the precondition is satisfied, i.e., the set Sat{P) X Sat{Q) . The 
shaded edges represent the transitions when the precondition is not satisfied, i.e,, the set 
(5 _ Sat(P)) X 5 , A similar case can be made for assertion a^. The intereection of the transitions 
associated with both assertions gives the Moore model for the specification. Id this particular 
model, nondeci^minism is used only to represent the choice of the next input In other cases, non- 
determioism cim be used to represent unspecified or don't care behavior such as output of ihc mul- 
tiplier while performing an add operation in a processor. 




Figure 23: Nondeterrmiiistic Moore machine mofiel for an inverter specification. 

The transition relation conesponding to an abstract assertion can be expn&ssed in terms of a char- 
acteristic fiinction. For every state variable € 5^ , introduce 2 variables denoting the present and 
next-state values for the state variable. Let the Boolean variables and d^ote the present and 
next-state values respectively* Define a Boolean function, ^t{F) , for an abstract formula R The 
fimction 1R^C{F) can be defined recursively^: 
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* 3ieC[true) = I 

♦ For simple abstract formulas appearing in the precondition, ^e((s.isO) = and 
!Rfl{s^isl) ~ p^. For siniple abstract formulas appearing in the postcondition, 
!RpC{s.MsO) = n. and J?ff(s,isl) « n^, 

• tK^KF^ and F^) = 3i€f(Fy) - mcC^F^) . 

• ^r(O-^F) - I ,and 5i>rf(I-^F) = 

For an abstract assertion, A = ^ the characteristic function for the transition relation corre- 
sponding to A is defined as X(A) = tHfiC(P) + (fi) - 

Let i i]3dex the set of abstract assertions. The conjunction of all Is tlie characteristic func- 

tion for the transition relation corresponding to the abstract specification. 

Consider the example of the inv^er. Let and n^^ be the present and next-state Boolean vari- 
ables corresponding to the abstract element In, Similarly, let Pq^^ and n^^^ be the Boolean vari- 
ables corresponding to Out- The characteristic functions corresponding to assertions and A2 
^ Xi-^i) - Prn"*""out ^(^2) = Pin-^^out • Therefore, the characteristic function 
corresponding to the specificaiion is X(^i) ' XCA^) « Pj^ © n^^^ . 

2.4 Extensions to Hardware Specification Language 

2.4.1 Symbolic Extension 

The pn^ceding section defined the scalar version of an abstract assertion. A symbolic abstract 
assertion can be used to define a set of scalar abstract assertions. Eadi abstract assertion can be 
assocjaied with a set of symbolic variables. All Boolean operations + are 

extended from the scalar to the symbolic domain, 

A symbolic abstract assertion is associated with a set of symbolic variables V, A symbolic abstract 
assertion is of the form: A = wh^ F and Q are symbolic abstract formulas of the form: 

1. + r^rresem the Boolean negation, conjunction, disjunction, exclusive 01^ 

NOR operators respectively. 
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• Simple abstract formula: {s^ is 0) and {s^ is 1 ) are symbolic abstraa formulas if e . 

• Coxijunction: (Fj and F^) is a symbolic abstract formula if and F2 are symbolic abstract 
fomnulas. 

• Domain Restriction: (e — ► F) is a symbolic abstract formula if F is a symbolic abstract for- 
mula and « is a Boolean expression over y. 

Note that the only change from the definition of a scalar abstract assertion is that the domain con- 
stmint can now be a Boolean expression ratbw than only 0 or L 

We introduce the notation {s^ise) as a shorthand for the formula 
(^-►(^^-isO))and(£"-^(j:.is 1)> . That js, we constraiD state element to have the particular 
symbolic Boolean value denoted by the expression e . 

As an example, a single symbolic assertion can specify an inverter as shown below. The variable a 
is a symbolic variable and is the negation operator extended to the symbolic domain. The sym- 
bolic assertion captures both assertions A^^ and A2 corresponding to values 0 and 1 for the variable 
a. 

(In is a) (Out is a) 

As another example, consider an OR operation. Let InA and InB be the inputs and Out be the 
output for the OR operation. Hie OR operation can be specified with a single symbolic abstract 
assertion as shown below. The variables a and b are symbolic variables and "I" is the disjunction 
operator extended into the symbolic domain. The symbolic abstract assertion captures 4 scalar 
assertions conesponding to 4 (i.e. 00,01, 10,1 1) possible values for variables a and b. 

(InA is a) and (InB is b) ^ (Out Is a| b) 

A symbolic abstract assertion can be converted into the corresponding transition relation. As 
before, for eveiy state variable e , introduce 2 variables denoting the present and next-state 
values for the state variable. Let the Boolean variables pj and denote the present and next state 
values respectively. Extend the Boolean fiinction, li(t[{F) , for a symbolic abstract formula as fol- 
lows: 
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• For simple abstract formulas appearing in the precondition, ;K&C{s> he) = p^^e. For simple 



For a symbolic abstract assertion, A = ^ 2, the characteristic function for the transition rela- 
tion corresponding to A is defined as X(A) = \f{3l_e((F) + iRfiCiQ)) , where V is the universal 

V 

quantification op^ator and V is the set of symbolic variables. 

As an example, consider the OR operation. Let p^j.^^^ and rii^A Boolean variables mtro- 
duced for state element Ink. Also, let and nj^g be the Boolean variables introduced for state 
element InB. And po^t ™^ ^Out ^ ^ Boolean variables introduced for state element Out. The 
characterisric function for the transition relation corresponding to the assertion is: 



2 A J, Vector and Data Handling Esilensions 

So far, the abstract elements have been limited to single bit and the symbolic variables have been 
limited to Boolean variables. The Hardware Specification Language has several extensions to ease 
the task of writing abstract specifications. The abstract elements are extended to represent differrat 
word sizes. A type definition section can be used to define a bit- vector, enumerations, and multidi- 
mensional array types. Types are used to define abstract elements and symbolic variables. Sym» 
bolic Indexing can be used to index tnio array types. Expressions over the symbolic variables can 
be defined using logical^ bitwise, anthmetic, and relational operators. 

Consider the example of a bitwise-OR operation for a SS-bit word size. Define fliree 32-bit abstract 
elements, SA, SB, and ST. State elements SA and SB serve as the source operands and ST serves 
as the target operand. Define two 32-bit symbolic variables a and b that denote the current values 
of tha SA and SB respectively. The bitwise-OR operation can he captured with a single symbolic 
abstract assertion: 



abstract formulas appearing in the postcondition, :f(fC(Sf is e) = n-^e. 




^Out 
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( S A is a) ami {SB IS b) ^ (S T is a|b) 

The abstract formula (SAisa) is a short form for the abstract fonnula 
(SA[0]isaO)and(SA[l]isal)and ...and(SA[31]isa31) . The symbolic abstract 
assertion captures 4^^ scalar assertions corresponding to all possible combination of assignments 
to variables a iind b. 

2.5 Syntax and Examples 

The syntax of the Hardware Specification Language is described in Appendix A- This section dis- 
cusses some examples. 

2,5*1 Bitwise-pR Operation 

The specification for a bitwise-OR operation on 32-bit source and target operands is sliown in 
Rgure 2.6. The specification can be divided into 3 separate sections: 1. Type Definitions, 2. State 
Declarations 3. Set of Asserdons. The type definition section defines a set of types required for the 
specification. The specification for the bitwise-OR operation defines a word as an array of 32 bits. 
The state dccliiratioo section defines the source and target operands. The assertion defines a bit- 
wise-OR operation. The assertion is associated with symbolic variables. The keyword LEADSTO 
separates the postcondition and precondition and corresponds to the symbol ^^^^ introduced ear- 
lier. 

MACHtNE BitwiseOr; 

TYPE WORD is ARRAY{31 to 0) of BH; 
STATE SA, SB. ST: WORD; 

Assertion { 

VARIABLE a. b: WORD; 

(SA is a) and (S8 is b) 

LEADSTO 
(ST is a I b) 

} 

ENDMACHINE 

Figure 2j6t Abstract specification for a bitwise-OR operation. 
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2.5*2 Stack 

Tlie complete specificalion for a stack is shown in Figure 2.7, The type definition section defines 
an enumerated type for the push, pop, and hold operations on (he siack. The state declaration sec- 
tion defines tfie abstract elements associated with the stack. The stack is defined as an array of 
1024 elements. The abstract element depth maintains a count of the number of items currently in 
the stack. The set of assertions defines the push, pop, and hold operations on the stack. 

Consider the assertion for the push operation. The WHEN keyword is used to define domain restric- 
tions. Note that a global domain restriccioD is placed on the jmsh assertion. Tlie global domain 
restriction ensures that the assertion does not specify the behavior when someone tries to push into 
a fiill stack- In this sense, the push assertion is ensuring that the system is not ovei^pecified. The 
realization is free to pick what it wants to do for a pash on a full stack. The push assertion should 
be read as follows: If in the precondition, op describes a push operation, dat ain has some value 
(say v), stack has currently d elements, and location i of the stack has some value u, then it» the 
postcondition, the top of stack should get value location i+1 of the stack should get value u, 
and the stack finally has d+1 elements. 

A similar case can be made for push and hold assertions. Note that the Verilog description in 
figun; 2.4 specified the illegal operation but not the hold operation. The HSI^ on the other hand, 
specifies the hold operation but not the illegal operation. The reason is due to different semantics 
far the two descriptions. The Verilog semantics is that if something is not specified or updated then 
it retains the previous state. The HSL semantics, however, is that if something is not specified, then 
anything is fair game. Therefore, the illegal operation is not specified.-Tlie hold operation^ how- 
ever, is explicitly specified to capmre the feet that the stack should retain previous state. 

The specification succinctly captures our abstract iK>tion of a stack. 
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MACHINE stacK; 

TYPE operations fe (push, pop, hold); 

STATE datain, dataOut: BIT; 
STATE control; operations; 
STATE depth: RANGE 0 to 1 024; 
STATE stack: ARRAY (1 023 to 0> of BIT; 

PushAssertion { 

VARIABLE i: RANGE 0 to 10^3; 
VARIABLE d: RANGE 0 to 1 024; 
VARIABLE u, v: BFT; 

WHEN (d< 1024) 

(control Is push) and (datain Is v) and (depth Is d) end (when (I < d) et^ckp] is u) 
LEADSTO 

{stack[0] is v) and (depth is d+1 ) and (when (i < d) slack[i+1] is u) 



PopAssertion { 

VARIABLE i: RANGE Q to 1 023; 
VARIABLE d: RANGE 0 to 1024; 
VARIABLE u. v: BIT; 

WHEN (d > 0) 

(control is pop) and (depth is d) and (stack{0] is v) and (when (0 < i < d) stackpl is u> 
LHADSTO 

(dataOut is v) and (depth is d-1) and (when (0 < c < d) stad^l] is u) 



HoldAssertion { 

VARIABLE I: RANGE 0 to 1 023; 
VARIABLE d: RANGE 0 to 1024; 
VARIABLE u: BIT; 

(control Is hold) and (depth is d) and (stack[i] is j) 

LEADSTO 
(depth is d) and (stackp] Is u) 



ENDSAACHINE 

Figure 2J' Abstract spedficatioii for a stack. 
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2.5.3 Addressable Accmniilator 

Consider the example of an addressable accumulator shown in Figure 2.8. The accumulator can 
maintain the sum of signals for 16 different channels, scoring the sums in the register array. There 
are two possible operations. The store operation stores the value on the data input in the addressed 
registei; The add operation takes the sum of the data input and the addressed register and stores it 
back in the addressed register. 




dataOut 



Figure 2.8: Addressable accumulator 

The abstract specification for the addressable accumulator is shown in Figure 2*9. The type defini- 
tion and state declaration sections define the data path to be 32 bits wide. A 4-bit address is 
required to address 16 channels in die register array- Assertions define the store and add opeiti- 
tions. An additional assertion is required to indicate that the rest of the registers (other than the 
addressed register) should maintain their state. 
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MACHINE accumulator; 

ryPE DATAWORD is ARRAY(31 to 0) of BIT; 
TYPE ADDRWORD is ARRAYO to 0) of BIT; 
TYPE OPS IS (Store, add); 

STATE op: OPS; 

STATE address: ADDRWORD; 

STATE dataln, dataOut: DATAWORD; 

STATE regtsters: ARRAY (15 to 0) of DATAWORD; 

StoreA&sertion { 

VARIABLE i: ADDRWORD; 
VARIABLE a: DATAWORD 

(op Is store) and (datain is a) and (addr^ Is i) 

LEADSTO 
(dataOut \s a) and (registers^} Is a) 

1 

AddAssenlon { 

VARIABLE i: ADDRWORD; 
VARIABLE a, b: DATAWORD: 

(op is add) and (dataIn Is a) and (address is i) and (registers[i] Is b) 

LEADSTO 
(dataOut Is a-t-b> and (registersO] is a+b) 

} 

MaintainStateAssertion { 

VARIABLE i, j: ADDRWORD; 
VARIABLE b: DATAWORD; 

WHEN (i !=D 
(address is i) and (registersQ] is b) 

LEADSTO 
(reQisters[fl is b) 

} 

ENDMACHINE 

Figure 2^: Abstract specification of an addressable aocamnlator. 
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2.6 Miscellaneous Issues 

The abstract specification defines a nondeterministic Moore machine. This opens the possibility of 
performing a high-level verification of the abstract specification as is done in the Symbolic Model 
Verifier (SMV)[33]- The abstract specification would serve as the state machine. Properties would 
be expressed in Computation Tree Logic (CTL)[30]. Symbolic model checking could then be used 
to verify properties of our abstract specification. Therefore, there are two different levels of verifi- 
cation, A hi^-level verification verifies properties of our abstract specification. And then a low- 
level verification is used to verify that the circuit fulfills the abstract specification. 
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Chapters 

Implementation Mapping 

The abstract specification describes the higb-level behavior of the system independent of any tim- 
ing or implementation details. Injplementation specific details are captured in the moping. As an 
exanqjle, the abstract specification describes the instruction set architecture of a processor. The 
details of the underlying implementation such as the pipeline structure, forwarding logic, pipeline 
interlocks, multiple instruction issue, and int^ace protocols are captured in the mapping. 

Our implementation mapping is defined as a set of map machines. A mzp machine is used to 
describe the temporal and spatial mapping for each abstract element in the specification. The map- 
ping nilaies the abstract element to a set of signals and internal nets in the circuit Abstract inputs 
and outputs can be mapped into protocols on a set of intoface signals in the circuit. Abstract state 
elements are m^ed mto a set of circuit state elements. A single map machine is used to map all 
instances of the abstract state element in the assertion. For ati abstract state element in the precon- 
dition, the map machine defines a set of constraints on the internal state elements and inputs in the 
circuit For the abstract state elenoent in the postcondition, the same map machine defines a set of 
allowed responses and state transitions. 

3.1 Related Work 

Bcatty laid down the fwmdation for the implementation mapping[l 3]. Each abstract element was 
mapped into a set of signals in the circuit as shown in Figure 3.1. An abstract input was mapped 
into a sequence of logic values on a set of circuit inputs. An abstract outjMit was mapped into a 
sequence of logic values on a set of circuit outputs. An abstract state was mapped into a sequence 
of logic values on a set of circuit states. The abstract stale can appear both in the precondition and 
postcondition of an assertion. The user defines a single mapping for the abstract state. For the 
abstract state in the precondition, the mapping defines a set of constraints on the circuit stales. For 
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the abstract stale in the postcondition, the mapping defines the set of acceptable logic vulaes on the 
circuit states. 

Abstract 




Circuit 

Figure 3.1: Mapping the abstract model to the drcnlt modcL 

Beatty, however, could express only a very limited set of traiporal behaviors. The mapping lan- 
guage was formulated in terms marked strings, which provided a formal model for aligning and 
overiapping tuning diagrams. Marked strings were defined over an alphabet The alphabet denoted 
logic values for signals in the timing diagram. The marks denoted the start and end of an operation 
and could be used to align and overlap successive operations. Marked stiings could express only 
bouoded single behavior sequences. Moreover, Beatty mapped abstract inputs and outputs into a 
set of unidirecdonal signals in the ciicuit. Several systems require abstract inputs and outputs to be 
mapped into protocols on a set of bidirectional signals as shown in Figure 3-2. 



Abstract 




Circuit 

Figure 3^: Extending the mapping for bidirectional inputs and outputs. 



PAGE113/277*RCVDAT7/18/20057:43:08PM [Eastern Daylight Tm 



07/18/2005 17:05 FAI 408 720 9397 



BST&Z 



S1114 



Our implementation mapping is defined in terms of a variation of Slate diagrams called control 
graphs. State diagrams allow users Co define unbounded and divergent behavior. The user can cre- 
ate an environment around the circuit and define complex nondetenninistic interface protocols. 

3.2 Control Graphs 

Control graphs are state diagrams with the capability of synchronization at specific time points. 
There are two types of vertices in a control graph: 1. Event vertices representing instantaneous 
time points. 2. State vertices repiesenting some non-zero duration of time- Event vertices are used 
for synchronizadon, A control graph has a unique event vertex with DO incoming edges cafled the 
source vertex and a unique event vertex with no outgoing edges called the sink vertex- Nondeter- 
minism is modeled as multiple outgoing edges from a vertex. In general, a control graph can be 
viewed as a "sausage" as shown in figure 33. The source and sink vertices serve as two ends of 
the sausage. There exists a path from the source to each state vertex in the control graph and from 
each state vertex to the sink of the control graph. 



state vertex 



soun^ 




Figure 33; General form of a control graph. 



As an example, consider the control gr^h shown in Figure 3.4. Vertices s, u and t are event ver- 
tices with s as die source vertex and t as the sink vertex. Vertices and vj are state vertices. The 
control graph represents that the system can be in vertex for an arbitrary number of times (0 or 
more) before transitioning to vertex 




Figure 3.4: Example control graphs 
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Mathematically, a control graph can be rq)Tesented as a tuple: G = {V.U.E, t) , wh^ 

• V is the set of state vertices^ 

• U is \hcs&t of event vertices. 

• E is the set of directed edges. 

• jj is the source^ sb U i 

• t is the sink, r e £/ . 

3.3 Basic Form of Implementation Mapping 

This section defines the basic form of the implementation maprping. The exact syntax of the raap- 
piiog will be described in later sections. The basic form of the mapping corresponds to the basic 
form of the abstract specification. Later on, we will extend the mapping langnage into the sym- 
bolic and vector domains and give several examples. 

The mapping uses a main machine to define the flow of control fof individual system operations. 
The main machine describes the pipeline stnicture for the implementation. Map machines are used 
to define the mapping for each abstract element. The map machines are syndironized with the 
main machine at specific time points to relate the flow of control of individual abstract elements 
widi the flow of control of the entire operation. 

Hie i^^^lementation mapping has four components^ 

• Setof node elements. 

• Hierarchy of state vertices, 

• Single main machine. 

• Set of map machines. 

The set of node elements N^^ represents a subset of nets in the realization. The node elements rep- 
resent inputs, outputs, and internal nets in the circuit The node elements are used to define node 
formulas. Node fcMmnlas are used in defining the hierarchy of state vertices and the set of mz;p 
machines and are of the form; 
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• Simple node formula: (n^ U 0) and (n . is 1 ) are node fbimulas if n . e JV ^ . 

• Conjunction: (Fj and is a node fonnula if F, and are node fomulas. 

• Domain Restnction: {0-*F) and (1 F) are node foiroulas if F is a node formula. 

In addition, we shall refer to true as a trivially true node formula. The domain restriction appears at 
first somewhat strange. The usefulness will.become apparent when we extend node formulas to the 
symbolic domain. 

The next few sections describe each component of the implementation mapping in detail. 
3.3.1 Hierarchy of State Vertices 

State vertices can be defined at varying levels of abstraction. The basic state vertex is a phase-level 
vertex. A phase-level vertex represents a period of time in which all external inputs are held fixed 
and the system operates until it reaches a stable state. Over and above the phase-level vertex, the 
user can define a hierarchy of state vertices. The hierarchy corresponds to the temporal hierarchy 
in the circuit- Each level m the hierarchy defines a state vertex as a control graph in terms of lower 
level state vertices. State vertices can be associated with node formulas, v/kdch are typically used 
to define the clocking scheme for the circuit 

As an example, consider a realization that uses two docks, 9^ and <[>2 , and a 4-phase non-over- 
lapping clocking scheme. A clock cycle, therefore, corresponds to 4 clock phases. A cycle-level 
state vertex can be defined as a control graph shown in Figure 3.5. Each state vtttex in the control 
graph is a phase^level vertex. The node formulas, shown in shadowed boxes, define the values of 
the clock signals in each clock phase. 



51 



PAai16l277*RCVDAT7/18/2fl()57:43:08PM [Eastern DayligMTm^^ 



07/18/2005 17:05 FAX 408 720 9397 



BST&Z 



©117 



Cycle-level vertex 




{ (<Ptfel)aiid(<p^bQ) I j P(yiisO)ai;Mi(<p2isO)~| 

I (y,is0) and(y2»s0) \ \ 

I 

F^ure 33: Defining a cyde-level state Tcrtexi. 

i 

Above a cycle-level vertex, the user can define an instruction-level vejncx. Consider a processor 

j 

where each instruction takes 2 cycles. An instruction-level vertex can be defined as shown in 
Figure 3.6. Each iostniction-level vertex corresponds to 2 cycle-level vertices or 8 phase-level ver- 
tices. 

I 

Instruction-level vertex ' 




Figure 3l6: Defining an instnicdon-icvel vertex. 

i 

Mathematically, a hierarchical state vertex is a tuple of the form: < V^, !7^, E^, s^, r^, , where 

» is the set of lower-level state vertices. At the lowest level, V^^ il the set of phase-level state 
vertices. 

• ^ ^ft' ^h* ^A' ^h^ ^® control graph. 

• is the labelling function that labels state vertices with node formuJas- 
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3.3,2 Main Machine 

The main machine defines the flow of control for individual system operations. The pipeline soruc- 
ture of the implementation is captured in the main machine. The main machine cao be viewed as a 
contmol graph with a nextmarker function, as shown in Figure 3.7. The source of the control graph 
denotes the start of the operation and the sink denotes the end of the operation. The control graph 
can be viewed as series of subgraphs. Each subgraph represents a pipeline stage. The nextmarker 
function relates an event vertex in a pipeline stage with a corresponding event vertex in the next 
pipeline stage. Typically, the nextmarker function defines the start and end of each pipeline stage. 



nextmarksr 



source 




Figure 3.7: General form of a main machine. 



As an example, consider a simple processor with fetch, decode, and execute pipeline stages. 
Assume that all instructions spend a single clock cycle in eadi pipeUne stage. The main machine 
for such a processor is shown in Bgure 3.8. The vertices F, D, and E are cycle-level state vertices 
representing the fetch, decode, and execute stages respectively. 




Figure 2Sv Example 1. Main machine for a simple processoc 



The nextmarker defines how individual operations can be stitched together to create execution 
sequences. Individual instructions can be stitched together to create execution sequences as shown 
in Figure 3-9. The machines , , are multiple copies of the main machine with the super- 
scripts denoting successive instnictions. The machine M* corresponds to the infinite execution 
sequence obtained bom stitching all instructions. Stitching is performed by aligning an event ver- 
tex of an instance of die main machine with the corresponding nextmarker event in the previous 
main machuie and composing the machines. In this case, composition is simply die cross-product 
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of all the macliines. Therefoie, the state vertex E^D^F^ in machine M* corresponds to the cross 
product of state vertices E * in machine , in machine , and in machine . 




Figure 3.9: Example 1- Stitching main machines togeth^ to form execution sequences. 



Mathematically, the main machine is a mple of the form: M = ( V^, U^:, E^, s^. t^, P^,> , where 

• ( V^, C/„. E^, s^. is the control graph, 

• 3„ is tl^ nextmaiiter function, ^^'U^^U^. This is a partial function. 

Hie nextmarker function, , is a partial function. Only a few event vertices will be in the inverse 
image of a nextmarker function. The rest of the event vertices will be considered ztftee vertices- 
For a free veitex, u e the nextmariter function is defined to be ^^iu ) = A . Stricdy 
speaking, the aextmarko: function should be of the form: : ^ C/^ u A . However, for the 
sake of shnplicity, we will use : ^ C/^, with the understanding that A r^resmts a free 
vertex. 

The nextmarker function places some restrictions on the control graph- The event vertex ^^iu^ 
should be a vertex cut of the control graph- The vertex cut divides the set of vertices into 2 sets, 
i.e. Y and Z , The set 7^. represents the set of vertices to the left of the vertex cut and the set 
2^ tepresentM the set of vertices to the right of the vertex cuL There cannot be any edges from ver- 
tices in to either P^("^) or vertices in . The restriction ensures that the pipeline is com- 
mitted to an instruction once it has started. 
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A nexdnarker has to be defined for the source vertex s^. The event vertex (3^(5^) is the time 
point where the next instruction can be siartetL For a nonpipelined circuit, P^y^^^m^ = 'm • 
the current opei^on must end before the next opwatioti can start- For pipeline circuits, however, 
the eveot vertex Py„(^„) is a cutset between source and sink. The cutset defines the time point 
where the next operation can be started, thus overlapping the current and next operations. 

Let us consider another example where a processor has two pipeline stages, namely, the fetch and 
execute stage. Further assume thai an instnicrion might spend an arbitrary number of cycles (1 or 
more) in each Stage. The main machine for such a processor is shown in Figure 3. 10, 




Figure 3,10: Example 2* Main machine for a processor. 

The Tiextmadcer function defines how instructions can be stitched to create execution sequences. 
Let us consider two instructions, and . They get aligned as shown in Figure 3. 1 1, Unfortu- 
nately, this is an overly restrictive alignment, since it requires the execute E ^ and fetch to fin- 
ish simultaneously^ 




Figure 3.11: Example 2. Alignment of niain machines. 



The restriction can be removed by describing a slighdy more complicated main machine. The 
main machme has to be augmented wi* a dummy vertex as shown in Figure 3.12. The dummy 
vertex represents the simation where the execute stage of the current instruction finished before the 
fi^ch stage of the next instruction, 
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Figurt 3.12: Example 2- Augmented main machine. 



The result of the cross-pnxluct construction of cwo instaaces of the augmented main machiuc is 
shown in Figure 3.1 3. State vertex E^F^ indicates that the execute stage of the first instraction 
overJ^s with die fetch of the second instruction. The edge firom E^f ^ to indicates that the 
execute stage of the first instruction finished before the fetch of the second instruction. The edge 
from E^F^ to e2 indicates that die execute and fetch finished simultaneously. Note that the cross- 
product construction automaUcally captures all possible cases for a sequence of two operations. 




Figure 3.13: Example 2. Compo^tion of machines aud M^. 



Th3s section has motivated die concept of composing main machines together to create execution 
sequences- As presented in tfxis section, the machine M* is an infinite machine obtained from tiie 
composition of infinite copies of die main machine. It is actually possible to obtain a closed form 
of die machine M* dial represents all possible execution sequences. Ait elegant and succinct r^re^ 
sentation for the mam machine and a closed form of die machine M* wiU be discussed later in 
Chapter?. 

333 Map Machines 

The map machines relate abstract elements in the specification to node elements in die circuit 
Each abstract input or output can be mapped into a protocol on a set of acUon and reaction nodes, 
as shown io Hgure 3.14. The action nodes are in the same direction as the abstract signal The 
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reaction nodes arc in the reverse 
the circuit 



direction. Abstract states are mapped into a set of action nodes in 



Abstract 




Action^ 

















I Action 
Reaction 



Circuit 



Figure 3.14: Role of actton and reacdon in the mapping. 

nie iniip machines define a spatial and temporal mapping for each simple abstract formula in the 
specification. A control graph is used to define the temporal aspect of the mapping. The spatial 
mapping is defined by node formulas on state vertices. Each state vertex in the control graph is 
associated with two node fonnulas. Le., the action and reaction node formulas. The action node 
formulas are used to relate abstract inputs, outputs, and state elements to action nodes in the cir- 
cuit The reaction node formulas are used to relate abstract inputs and outputs to reaction nodes in 
the circuit The map machines are not completely independent A iynchronkation function maps 
event vertices in the map control graph to event vertices in the main control graph. The synchroni- 
zation function relates tlie flow of control of the abstract element to the flow of control of the entire 
opemuon. The map machine can be viewed as a control graph with node formulas on state vertices 
and synchronization on event vertices as shown in Figure 3.15. Event vertices in the map machine 
are synchronized to event vertioes in the main machine. Each state vertex is associated with node 
formulas. The action node formulas are shown in the upper half of the shadowed box and reaction 
node fonnulas are shown in the lower half of the shadowed boxes. 
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Main 




source 



sink 



Map Machine 

Figure 3,15: General form of the map machine. 

As an exanople, assume an abstract ALU that is fetching an operand A from an abstract register 6le 
as shown in Kgure 3.16. Consider a circuit in which the register file indicates that the openmd is 
available with a r dyA signal and the ALU^acknowledges receiving the operand with an ackA sig- 
nal 



Abstract 




Abstract 


Register 




ALU 


File 







Abstract System 



rdyA 
datA 



n 









Register 


rdyA ^ 


ALU 


Rid 


ac)cA 





Protocol Circuit 
Figare 3J6; An abstract system aiid the coiT«poQdiDg drenrt and protocol 

■me signals datA and rdyA serve as action nodes since they ate in the same directioo as the 
abstract signal A. The signal ackA serves as the reaction node since it is in the reverse direction. 
Consider the simple abstract foimula (A is 0) . The map machine for this simple abstract formula. 
Written MapiAisO) , is shown in Figure 3.17. The machine is defining the protocol shown in 
Figure 3.16, sis a control graph with action and reaction node formulas. The action node formulas 
are shown in the upper half and the reaction node formulas in the lower half of the shadowed box. 
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The register file indicates thai the operand is available by activating the ready signal il) state vertex 
J. The agister file has to wait for an arbitniry number of cycles before the ALU accepts the oper- 
and and activates the acknowledge signal in state vertex K. Finally, both the ready and acknowl- 
edge signals are d^-activated in state vertex L. Hie synchronization function is specified so that the 
map machine is synchronized with the fetch stage of the main machine. 




(r dyA is 1) and (dat A is 0) 




(rdlyAisO) 


(aCikAisO) 




(ackAisO) 



F%im 3.17: Map machine fivr (A is 0). 

Later on, the map tnachinCS will be used to define flje stimulus and response for a simulation based 
verification strategy. The action node formulas define the Btimulus, and the reaction node formulas 
define the response for the simulator. Assume we are veri^ the ALU in Figure 3.16. The 
abstract signal A serves as an input to the ALU and wiH appear in the precondition of the abstract 
assertions. The r dyA and dat A signals serve as stimulus signals and ackA serves as the response 
signal for the ALU. Now, consider that we are verifying the register file. The abstract signal A 
serves as an ouiput of the register file and will appear in the postcondition of the abstract asser- 
tions. A miiTor operation is used to reverse the roles of the action and reaction formulas for 
abstract elements in the postcondition. The machine obtained from the minor operation is shown 
in Rgure 3.18. The ackA signal serves as the stimulus signal and the rdyA and datA signals 
serve as the response signals for the register file. This section has motivated the concept of using a 
single map machine to describe the interface protocols for interacting subsystems. A detailed 
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description of the mirror operation and how these map machines are used to verify sabsystems wiU 
be discussed later in ChapCCT 4. 



(ackAisl) 



(rdyAis I ) and (data is 0) 




(ackA-isO) I 
(rayAis l)and(datAkO) | 




(ackAisO) 



(rdyAlsO) 



Figojre 3.18: Mirror of map iiiad»iiie for (A is 0). 

A mathematical definition of the map machine requires some terminology introduced in 
ScctioD 23. For convenience, the relevant terminology is repeated here. The set S„ is the set of 
abstract elements in the abstract specification. Abstract elements are used to define abstract formu- 
las. Abstract formulas are of the form: simple abstract formulas, conjunction, and domain restric- 
tion. Let represent the set of all simple abstract formulas. Each abstract element * j e is 
associated with two sinq>le abstract formulas, i.e. (S; is 0) and {s-^ is 1 ) - Therefore, if n = \S^\ , 

Each simple abstract formula is mapped into a map machine. The mapptag is said to be complete 
if each simple abstract formula in 7 ^^^c, is associated with a map machine. A complete mapping, 
therefore, requires 2n map machines. A map machine for a simple abstract formula s € 7 ^^^u 
can be represented as a mple of the form: !»f<ip(5 ) = < V^, U^, Eg. t^, o^, , where 

• ( U^. E,. Sg. r,) is the control graph. 

• is the labelling fimctioi) that labels state vertices with action node formulas. 

• <5^ is the labelling function that labels sute vertices with reaction node formulas. 
. T, is the synchronization function. r^zU.-^U^. TTiis is a partial function. 

The map machines for abstract state elements will use only action node formulas. Also, abstract 
inputs and outputs that are mapped into unidirectional signals in the direction of the abstract signal 
will use only action node formulas. For these map machines, the reacUon node formula is assumed 
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to be the trivially true node fonnuia, i.e. V(v^ e V^) , a^(v^) = true , We shall refer to these 
machines as single-sided map machines. Map nmchines that use both the action and reaction node 
formulas are referred to as double-sided map machines. Double-sided map machines are used to 
map abstract inputs and outputs into a protocol on a set of bidirectional signals in the circuit 

The synchronization function is a partial function, Tn atypical map machine, only a few event ver- 
tices will need to be synchronized to the main control graph. The rest of the event vertices will be 
free vertices in the sense that they are not required to be synchronized to a specific point in the 
main conuol graph. For a free vertex, € U^y the synchronization function is defined to be 
T^(u^) - A , Strictly speaking, die synchronization function should be of the form: 
; CA^ u A. For the sake of simplicity, however, we will use : C/^ -> with the 
understanding that A represents a 6ee vertex, 

3.4 Extensions to Mapping Language 

3.4.1 Symbolic Extension 

The precedmg section defined the scalar version of the mapping language. The language can be 
extended into the symbolic domain. 

A symbolic node formula can define a set of scalar node formulas, A symbolic node formula is 
associated with a set of symbolic variables V, and is of the form: 

• Simple node formula! (n^isO) and (Mj-isI) are symbolic node formulas if n, e - 

• Conjimcdon; (Fj and F^) is a symbolic node formula if Fj and aie symbolic node for- 
mulas, 

• Domain Restrictioxi; {e -^F) is a symbolic node formula if F is a symbolic node formula 
and e is a Boolean expression over V. 

Note that the only change from the definition of a scalar node formula is that the domain constraint 
can now be a Boolean expression rather than only 0 or 1. 
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We introduce the notation (rt.ise) as a shorthand for the foimula 
(e (n, is 0)) and {e (n,- is 1)) . That is, we constrain node element n,. to have the particular 
symbolic Boolean value denoted by the expression e . 

In die basic form, each state element, s^, was associated with two map machines, S^apU^ is 0) 
and 5»fa>(j,is 1) . A symbolic map machine can be used to capmre both machines. A Boolean 
variable is used to define a symbolic map machine, Mapis^ is v^) . The variable serves as a 
fonnal argument thai can be replaced by an arbitrary Boolean expression e to obtain the machine 
iMapis^ is e) . The symbolic map machine uses symbolic node formulas defined ovct the set of 
symboUc variables V = u {v^} , where V, is the set of local symbolic variables associated 
with the map machine. 

As an example, a symbolic map machine 9iaf[K is a) can be used to define two scalar map 
machines, MafiK is 0) and i»fcp(A is 1) . The variable a serves as the formal arguraem. 

3.4 J Vector and Data Handling Ejrtensions 

So far, the nodt; elements have been limited to single bit and the symbolic variables have been Um- 
ited to Boolean variables. Data handling extensions can be used to ease the task of writing the 
mapping. The user can define an array of nodes and use symboUc mdexing to index into these 
arrays. The an-ay of nodes can be aliased into actual net names In the realization. The user can 
define complex symbolic variables. Expressions over symboUc variables can be defined using log- 
ical, bitwise, arithmetic, and relational operators. 

As an example, consider the abstract assertion for a bitwise-OR opei-ation introduced in 
Section 2.4.2. The mapping language requires three map machines. i.e., !Wop(SAisu), 
MapiSB is v) and !Map{&1 is w) , where u, v, and w are 32-bit symboUc variables that serve as 
formal arguments for state elements SA, SB. and ST respectively. Note that each of these symboUc 
machines captures 2^2 scalar map machines corresponding to all possible assignments to the sym- 
bolic variables. 
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3.5 Syntax and Examples 

The syntax of the mapping langaage is described in Appendix B. This section discusses some 
cxampU'-s- 



3.5.1 Addressable Accumulator 

The abstract specificatiOB for the addressable accumulator was shown in Figure 2.9. Let us con- 
sider a dicuit with the timing of the add operation as shown in Bgure 3.19. The circuit uses a 4- 
phase Don-overlapping clocking scheme. The Clear signal defines the add or store operation. 

Current Cycle Ne)ct Cycle 



1 






n_ 


u 


















3 



phil 
phi2 
Clear 
addr 
in 

reg-[i3 
out 

Figure 3.19: timing for add operation in the accnmulator. 

The mapping for such a circuit, shown below, can be divided into 5 s^aiaie sections: 1- Node de«> 
larations 2. AJias definitions 3, Hierarchical state vertices 4, Main machine and 5, Map machines. 
We will discuss each of these sections in detail. 

MACHINE accumulator; 

Node Declarations 

Alias Definitions 

Hierarchical State Vertices 

Main M^hine 

Map Machines 
ENDMACHINE 
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"^fhe node declaration section is shown below. This section defines all ihe nodes used in the map- 



NODE phi1,phi2, Clear; 
NODE regI31 to 0][15to 0]; 
N0DEaddr(3 to 01; 
NODE in[15 to 0], oiJt[15 lo 0]; 



The alias definition section is shown below. The aliases map node elements into actual net names 
in the realization. As an example the node element addr[15 TO 0] is mapped into nets 
Add3C - 1 5, Adclr .14- Addr . 0. 



ALIAS regMM {Re9.}Ix}{.}[y]; 
ALIAS addrtx] {Addr.}[x]; 
ALIAS in[xl {ln.}M; 
ALIAS 0UtM{Out}M; 



The hierarchical state vertices section is shown below. Each hierarchical level i& defined as an 
ENTITY in the mapping. The entity in the figure is defining the 4 phase non-overlapping clocking 
scheme shown in Figure 3.5. The vertex declarations and next definition define the control graph. 
The control graph is defined in terms of phase-level state vertices. The label definition defines the 
node formulas on the state vertices. 



ENTITY cycle { 

VERTEX PI . P2, P3, P4: PHASE; 
VERTEX start, u, v, w, end: EVENT; 
NEKT{ 

start: P1; 
P1:u; 
u: 92; 
P2: v; 
v: P3; 
P3: w; 
w: P4; 
P4: end; 

} 

LABEL { 

(phil IS at PI) and (phi2 IS '0' at PI) and 
(phI1 IS '(y at P2) and (phi2 IS *0' at P2) and 
{phi1 IS '0' at P3) and (ph"2 IS 'V at P3) and 
{phi1 IS '0' « P4) and (ph12 IS '0* at P4) 

} 

) 



The main machine, shown below, is defined as the top-level entity. The control graph defines the 
flow of control for store and add operations. The nextmarker defines the time point where the next 
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operation can start. A pictorial view of the main n^achine is shown in the upper half of Figure 3.20. 
Each state vertex is a cycle-level slate vertex consisting of 4 phases. 



ENTITY main { 

VEFTTEX CurrCyc. NextCyc: cycle; 
VERTEX: cuffStart, nexiStari, done; EVENT; 
NEXT{ 

c3urrStart: CurrCyo; 
CurrCyc: nextStart; 
nextStart: NextCyc; 
NextCyc: done; 

} 

NEXTMARKER (currStart: nextStart}; 



The single-sided map machine for the abstract elemait op is shown below. The synchromzation 
function maps the start of the map machine to the start of the main machine. The labelling defines 
the action node formulas. The reaction node fonnula is assumed co be the tnvially true node for- 
mula. A pictorial view of the map machine is shown in the lower half of Figure 3.20- 



MAP (op IS 0) TO { 
VERTEX Cyc: cycle; 
VERTEX start end: EVENT; 
NEXT{ 

start: Cyc; 
Cyc: end; 

} 

SYNCH {start: main.currStart); 
CASE (o){ 

IS store: 

LABEL {Clear is '1 ' at Cyc.P3} 

IS add: 

LABEL {Clear Is '0' at Cyc.P3} 

} 

} 
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main . currStart 

Main 




CurrCyc 



NextCyc 



main, done 



Clear = (o=srore)? 1 :0 



start 



Cyc 



Figure 3^20; Pictorial view of the main and map machine for the accumuteton 



The rest of the map machines are similar and are shown below. 

MAP{fegister(i]ISr)TO{ 
VERTEX Cyc: cycle; 
VEOTEX 3t3ar% end: EVENT; 
NEXT {start: Cyc; Cyc: end;} 
SYNCH {start main.cunrSlart}; 
LABEL {reg[i] Is r at Cy&P3]| 

} 

MAP (address IS u) TO { 
VERTEX Cyc: cycle; 
VERTEX start, end: EVENT; 
NEXT {Start: Cyc; Cyc: end;} 
SYNCH {start: maln-currSiart}; 
LABEL (addr ts u at GyG.P3}| 

} 

MAP (datalnlSd)TO{ 
VERTEX Cyc: cycle; 
VEfOEX start, end; EVENT; 
NEXT {start: Cyc; Cyc: end;) 
SYNCH {start: main.currStart); 
LABEL {In Is d at Cyc. P3} 

} 

MAP(dataOutlSd)TO{ 
VERTEX Cyc: cycle; 
VERTEX start, end: EVENT; 
NEXT {start; Cyc; Cyc: endj 
SYNCH {start: mainxurrStart}; 
LABEL (out Is d at Cyc.P1 } 

} 



66 



PAai31/27rRCVDAT7mi20l>57:43:08PM (Eastern DayBghtm^^ 



07/18 /2005 1 7 : OS FAX 408 720 9397 



BST&Z 



@1132 



The abstract elements op, address, and datain are abstract inputs that will appear only in die 
preconilmon. The node formulas in the map machines for these abstract inputs define the scimulus 
for the circuit. The abstract element d&taOut is an abstract output that will appear only in the 
postcondition. The node fonmilas in the map machine for dataOut define the desired response 
from the circniL The abstract element regis ter[i] is an abstract state thai can appear both in 
the precondition and postcondition. In the precondition, the node formulas in the map machine for 
the abstract register define constraints on internal state elements in the circuiL hi the postcondition, 
the node formulas in the same map machine define the desired state transitions for the circuit 

3-5»2 Pipelined Addressable Accumulator 

Let lis consider another realization of the addressable accumulator shown in Figure 3.21 . The pipe- 
line register Hold has been mcotporated to achieve a greater throughput by overlapping the addw 
and register write operations. While the adder is performing the sum for the current cycle, the 
value 6om the previous cycle is written into the register array. If the previous address in the con- 
trol logic is the same as the current address, then the accumulator bypasses the register array and 
transfers the data directly from the Hold register to the input of the adder- 




Clear 




Figure 3u21: A pipelined addressable accnmulaf or realizatioii. 
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The timiixg for the add operation in this pipelined addressable accumulator is shown in 
Figure 3.22. Note that if the previous address k is the same as the current address i, then the add^ 
takes in the data from the Hold regist&r. Else, if the two addresses are different, then the data is 
taken from the register jSle. 

Previous Current Next Cycle 



phxl 

phi2 
Clear 

addr 
in 

reg[i] 

Hold 

out 



Figure 32Z: Timing for die add cpeiatkua in the pipelined accumulator. 



The main machine for the pipelined accumulator is shown below. The main machine has 3 cycle- 
level state vertices corresponding to the previous, cuirent, and next cycle. 



ENTITY main { 

VERTEX PrevCyc, CurrCyc. NexiCyc: cycle; 
VERTEX prevStart, currStart, nexiStart, done: EVENT; 
NEXT{ 

prevStart PrevCyc; 

PrevCyc: CurrStart; 

currStart: CurrCyc; 

CurrCyc: nextStart; 

nextStart NextCyc; . 

NextCyc: done; 

) 

NEXTMARKER {prevStart currStart); 
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The pipelined accumulator compar&s the current address with the previous address. The previous 
address is defined in an append assercion section as shown below. Note that the address k is syn- 
chronized with the start of the main machine. The start of the main machine corresponds to the 
previous cycle. 



APPEND AddAssertion { 

VARIABLE k: ADDRWORD; 

(address IS k SYNCH main.prevStari) LEAOSTO () 

} 



Most of the map machines for the pipelined accumulator are the same as for the nonpipelined ver- 
sion. The map machine for the register file, however, is a little more complicated and is shown 
below. This is a state dependent mapping since it is dependent on the previous address. The COND 
keyword is used to define state dependent mappings. The abstract register is mapped into the 
Hold register if the previous address k is the same as the current address i. Else the abstract reg- 
ister is mappwJ into the register file reg. 

MAP (registerp] IS r) TD { 
VERTEX Cyc: cyde; 
VERTEX start, end: EVENT; 
NEXT {5tart: Cyc; Cyc: end) 
SYNCH {start: main.currStart}; 
COND (address IS k SYNCH main.prevStart) { 
WHEN(i==k){ 

LABEL (Hold KS r at CycP2} 
)ELSE{ 

LABEL {re£|[i] Is r at Gyc.P3} 

} 

} 

} 



Consider the precondition of the add assertion in Figure 2.9. The append assertion section defined 
the previous address to be the symbolic value k. The abstract formula (register[i]isb) in 
the precondition will be mapped into a constraint on Hie pipeline hold register and the register 
array in the circuit, TTie hold register will be constrained to the value b urKler the condition 
i k , and the register array will be constrained to the value b under the conditicm i ^ k . Now^ 
consider the postcondition of the add assertion. The previous address in the postcondition is the 
symbolic address i. The abstract formula (regi5tei:[i]isa + b) in the postcondition will 
be m^ed into a check for the value a + b in the hold register. 
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3.6 Miscellaneous Issues 

One of the concerns in this work is that the implementation mapping can become very complex. 
An area of focus for fuaire work would be to simplify or automate the generation of the mapping 
information as much as possible. Another possibility is to explore notations such as annotated tim- 
ing diagrams for expressing the mapping. Formalisms on timing diagrams have been studied ear- 
lier[85][861. Some of the concepts might be applicable to this problem- 
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Chapter 4 

Trajectory Generation 

The previous two chapters have described the form of the abstract specification and the implemen- 
lacion Tnapping- The abstract specification defines each op^ation of the system as an abstract 
assertion. Each abstract assertion is defined in the form of a precondition leads to a postcondition. 
The picconditTon and postcondition are abstract fornmlas that operate on abstract elements. The 
implementation mapping provides a temporal and spatial mapping jfrom the set of abstract ele- 
ments to the set of node elements in the circuiL 

The trajectory generation phase takes the abstract specification and mapping and generates the tra- 
jectory specification. The trajectory specification consists of a set of trajectory assertions. Each 
abstract assertion gets mapped into a trajectory assertion. Each abstract formula is mapped into a 
trajectory formula. The trajectory assertion is a control graph that captures all possible nondeter- 
ministic cases for the circuiL We use the terms trajectory specification and trajectory assertion 
partly for historical reasons. Our trajectory assertions are a generalization of the trajectory asser- 
tions introduced by Seger and BryantllS]. The justification is that a trajectory assertion defines a 
set of trajectories in the simulator. Informally, a trajectory can be considered to be a sequence of 
states tliat represents an acceptable behavior of the circuiL A rigorous definition of a trajectory will 
be given later in Chapter 6. 

4.1 Related Work 

Seger and Bryant introduced the terms trajectory formula and trajectory assertion[t 8]- The trajec- 
tory foitnula used the next-time operator to define restrictions on circuit nodes for a finite duration 
of time. In effect, their trajectory formula was a single sequence of state vertices labelled wjth 
action node formulas. Seger and Bryant described a simple trajectory assertion in the form of an 
implication, i.e. the antecedent implies the consequent They used the sequence and iteration con- 
structs to create more complex trajectory assertions. In effect, their simple trajectory assertion was 
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a single sequence of state vertices labelled with action and reacdor node formulas. The iteration 
construct augmented the single sequence with a limited set of loops. In particular, they did not 
allow nested or interacting loops. Our trajectory formulas and trajectory asserlions axe arbitrary 
control graphs with state verdces labelled with both action and reaction node formulas. 

Beatty used the abstract specification and implementation mapping to generate a trajectory specifi- 
cation[13]. The mapping, however, could express only a limited set of temporal behaviors, Beatty 
described the mapping in terms of a formulation called marked strings that could express only 
bounded single behavior sequences. Abstract inputs and outputs could only be mapped into a set of 
unidirectional signals in the circuit In effect, the mapping was limited to single sequence of state 
vertices labelled with action node formulas. Beatty defined an overlapped concatenation operator 
over marked strings that was used to generate the trajectory assertion. The resultant trajectory 
assertion was a single sequence of state vertices. 

Our map machiocs are arbitrary control graphs with both action and reaction node formulas. Reac- 
tion node formulas are used to map abstract inputs and outputs into protocols on bidirectional sig- 
nals. The trajectory generation phase essentially performs a cross-product construction of the 
control graphs. The resultant trajectory assertion is a graph labelled with both action and reaction 
node formulas. 

The next section gives a brief overview of trajectory generation. A detailed description is given in 
subsequent seciiotis. 

4.2 Overview of Trajectory Generation 

An abstract formula gets mapped into a trajectory formula. The trajectory formula is the set of the 
trajectories defined by the abstract formula for a particular implementation. For the moment, con- 
sider a trajectory formula to be a control graph with node formulas on state vertices and a synchro- 
nization fimction. Later on, we will give a more rigorous mathematical definition of a trajectory 
formula. Notice that a trajectory formula has the same form as a map machine. The map machines 
can serve as trajectory formulas for the simple abstract formulas. Given the map machines, the tia- 
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jectory formula for an abstract formula AF, written TF (AF) , can be automatically computed 2s 
follows: 

♦ Simple Abstract Formulas: rt^is^isv) = i^{ap(5-lsv) , where ve {0. ]} - 

• Confunction: T^{AF^ andAFj) = TJ^iAF^) HTjT'CAF^), whexe || denotes the compose 
operator. Composition amounts to taking the cross-product of the two control graphs under 
restrictions specified by the synchronization function. Assume that Vj and V2 are state vertices 
in the trajectory formulas for AF^ and AF2 respectively. Further, assume that ANF^ and| 
RNF^ are the action and reaction node formulas associated with state vertex . And AJVFj 
and RNF2 ^ the action and reaction node formulas associated with state vertex V2 . Then, the 
action and reaction node formulas associated with the vertex (v^ in the cross-product con- 
strucition are (ANF^ and ANF2) and (RNF^ and RNF2) respectively- This is shown pictori- 
ally in Figure 4.1. Intuitively, the cross-product construction captures all possible interactions 
between the two machines- 




{ANF^ and AATFj) 



(RNFiWdRNF2) 




^27 (AF, and AFj) 
Figure 4.1: Ik^ectory formula for coiuunctioiu 



• Domain Restriction: ay(e-^AF) = ^rir(AF)|^ .where ^/^^^ denotes the fact 
that and are replaced by €-*a^ and e-^a^ respectively. Assume that v is a state y&r- 
tex iu the trajectory formula for AF, with action node formula ANF and reaction node formula 
RNF. The action and reaction node formulas associated with the vertex v for the trsyectory 
fomiula (c-^AF) are (e-^ANF) and {e^RNF) respectively. This is shown pictorially 
in Figure 4.2. Dituitively, the domain restriction is specifying that the abstract formula AF has 
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to hold only when the expression e evaluates to true. Therefore, the action and reaction node 
fojrmulas have to define a set of stimuli and responses for the sinaulator only when the expres- 
sion evaluates to true, 



Figure 4^: IVajectoty foiTnuIa for domain restriction. 

For an abstract assertion A = P^Q, ^{P) and ^Z]f(g> are the trajectory formulas associated 
with the precondition and postcondition respectively. The trajcctoxy assertion ccwesponding to A 
can be automatically computed as 1Sl{A} = T!F {P) // [^7 {Q}]^ • where // is the shift-and- 
compose opeiaiion and the superscript ^ is the mirror operation. The miiror operation reverses the 
role of the action and reaction node formulas. The shift-and-compose operator shifts the start of 
the niachine Tlf(Q) to the nextmarker of the source in the main machine and then performs the 
composition. This is shown pictoriaUy in Figure 4.3. Assume that v j and are state vertices in 
the trajectory formula for the precondition and postcondition respectively. Further assume that 
ANF-^ and RNF^ are the action and reaction node formulas associated with vertex v j . Similarly 
let ANF2 fimd RNF2 be die action and reaction node formulas associated with vertex - The 
mirror operation reverses the role of the node formulas ANF2 and ^^^2 *^ postcondilioti- 
Consider the v<irtex <v j, v^) m TMP Q) • The action and reaction node formula associated 
with vertex {vj. are {ANF^ andRNF2) 2nil{RNF^ BndANF2) respectively. 



ANF 
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{ANFi and RNF^) 





Figure 4^: Generatiiig the trajectory assoitign- 



In the precondition, the action node foimula ANF^ refers to circuit inputs and state elements that 
define the stimulus and current state for the circuit The reaction node formula RNF^ refers to cir- 
cuit outputs thai define the desired response from the circuit In the postcondition, however, the 
action node formula AiVF^ refers to circuit outputs and state elements that define the desired 
response and state transitions. The reaction node formnla RNF^ refers to circuit inputs that define 
the stimulus for the circuit In the trajectory assmioo TJHP ^ Q) 7 the action node formulas 
define the stimuli and current state for the circuit Action node formulas are used as generators 
since ihey generate low-level signals for the circuit The reaction node formulas define the desired 
response and state transitions. Reaction node formulas are used as acceptors since they define the 
set of acceptable responses from the cdrcuit 

Inctdentally the shift-and-compose opeirator was also used to stitch operations together to form 
execution sequences in Section 3.3.2, with the slight variation that the main machines were not 
associated with any node formulas. 

The above overview defines the basic coneys of trajectory generation. The actual details are a bit 
more complicated. The main xeason for the added complication is that the map machines are not 
synchronized with each other but are all synchronized to the main machine. This requires the main 
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machine to be brought into the composition process. The next few sections deal with the actual 
details of trajectory generation. 

4,3 Trajectory Formula 

Let us now rigorously define a trajectory formula. A trajectoiy formula for an abstract formula AF 
is defined to be a tuple of tlie form: TJ^ ( AF) = < U^, E^, j^, t^, c^, a^. , where 

• ( Vj, U^, Ej, is a control graph. 

• is a labelling function that labels state vertices with action node formulas. 

• is a labelling function that labels state vertices with reaction node formtilas, 

• is a projection fiinction that relates event voices in the trajectoiy formula to event vertices 
in the main machine, T^:U^-^ . This is a total function, i.e., relates every event vertex 
in the trajectory formula to an event vertex in the main machine. 

The previous stu:tion presented a simplified overview of trajectory generation. Unfortunately, the 
map machine cannot serve as the trajectory formula for simple abstract formulas. The reason is 
that the map nutchines are synchronized to the main machine. The main machine has to be brought 
in to the definition of the trajectory formula. Let fafain = i^m* ^m* ^m' ^m' 'm* ^rr) I'epresent the 
main machine. A rigoroiis mathematical definition of the trajectory formula requires two forms of 
the compose operator. We shall refer to these as the dot'Composition and the parallel-composition 
op^tors. The symbol * will be used to denote the dot-composition operator and the symbol 1 1 wiU 
be used to denote the parallel-composition operator. Given these operators, the trajectory formula 
can be recursively defined as: 

• Simple Abstract Formulas: 77 is ^ is v) = l^fairf C^^ap(s^isv} ^ 

• Conjunction: IT (AFi and AF^) = 1^(Af^)\\r!F(AF2)^ 

• Domain Restriction: T^FC^-^AF) = <Vj, J/j,£,,fj,/^e->a^,e-»o^,T^), 

Most of the complexity due to synchrocdzaiion is captured in the dot-composition operator. The 
next few sections describe the composition operators in detail 
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4.4 Dot-Composition 

A high-IeveJ view of the dot-composition process is shown in Rgiire 4.4. We are given the nvain 
machine and the map machine iMapis- is v) . Some of the event vertices in the map machine are 
Synchronized to event vertices in the main machine. The dot-composition process will result in the 
trajectory formula is v) . All the event vertices io the trajectory formnJa will be related to 

event vertices in the main machine. 




Figyre 4,4: High-level view of the dot-composition process- 



There arc three separate steps involved in the dot^omposition ^a£» • 3^ap(s. is v) : 

• Augment the map machine is v) . 

• Piecompose iJi€ain and augmented 5l^ap(5. is v) | 

• Prune the graph obtained from the precomposition step to generate u^ain • ^ap{s^ is v) , 
4,4.1 Augment Map Machine 

The precompose seep requires that the source of the map machine is synchronized with ttie source 
of the main machine and the sink of the map machine is synchronized with the sink of the main 
machine. In general this might not be the case. The purpose of diis step is to augment the map 
machine with dunmiy vertices to ensure this condition. 

Let us consider a map machine of the form; v^ap{s^ is v) = <K^, U^. £j, a^, . Let 

us first consider the case where the source of the map machine is not synchronized with the source 
of the main machine^ i.e. T^(^ j) ^ . Then, the map machine is augmented with a dummy state 
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vertex and a new source vertex as shown in Rgure 4.5. The new source vertex is synchro- 
nized with the source of the main machine i.e. T^C^"^) - , The dummy state vertex is associ- 
ated with the trivially true node formulas i.e. <5^(v^) — true and o^{v^) - true . 




Figure 4^: Aagmentiikg source of map machine. 



Let us now consider the case where the sink of the map machine is not synchronized with the sink 
of the main machine i.e. T^(r^) ^ . Then the m^ machine is augmented with a dummy vertex 
and a new sink vertex t^ as shown in Figure 4,6. The new sink vertex is synchronized with the 
sink of JJae main machine Le. T^(^^) = . The dummy state venex is associated with the trivi- 
ally true node formulas i.e. cy^(v^) = true and c^^Cv^) = true . 




Figure 4j6: Aagmenting sink of map macdiine. 



4AJZ Precomposition 

A detailed description of the precomposition operator requires some additional mathematical nota- 
tion. Let us consider a control graph of the form: < V, U, E, /) . An instantaneous path is defined 
to be p s= Wq.w^,h'2, + x> w^^U^ V(i=5l...n) and (m'j-, w.^^) e £ » 

V(i = . In other words, an instantaneous path is a path in the control graph where every 

vertex except the endpoint vertices have to be event vertices. The endpoint vertices can be eith^ 
state or event vertices- Define the functions, AwdJ JUj^ and muCfvcof a path as ficad{p) = wq, 
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and suffi?c(p) - W2 ^n + l^ ^^^fi^ip) = degenerate case, 

an instantaneous path can consist of a single vertex i.e. p = ivq. In this case fUad{p) = WQ,and 
stiffi?^(p) = A, and midfi^ip) - A. 

Let (y^, C/^, s^^, t^. represent the main machine and let < V^, U^, E^, j^, a^, 
represent the augmented map machine. Since this is an augmented machine, the source is syn- 
chronized with the source of the noain machine i,e, T^is^) « . Also the sink is synchronized 
with the sink of the main machine i-e. ^^i^^) " * Prfrcomposition is the cross-product of the 
two control graphs under restrictions specified by the synchronizatioD function. Pre-composition 
results in a trajectory formula of the form: < V, 17, jE*, s, r, o^, ^, T> , where 

• V is the set of state vertices, V^V^X V^. 

• C7Lsthesetofeventveitices\ U c(U^xU^)u(U^xV^)uiV^xU^) ^ 

• B h the set of edgesj 

• 5 is the source, s = {s^, . 

• r is the sink, r = Om'O^ 

• labels state vertices with action node fcwmulas. For state vertices e and v^s V^, 
and the state vertex <v^, v^eV, die associated action node formula is 

• <y_ labels state vertices with reaction node formulas. For state vertices € y„ and e V,., 
and the state vertex (v^, Vj)eU, the associated reaction node formula is 

• T relates event vertices to event vertices in the main machine. For vertices w_ € C/ and 
w^e V^uU^, and the event v^tex («^, w^e U, the associated projection function is 

The pseudo code for the prccoiiq)Osition algorithm is shown in Figure 4.7. The routine is called as 
preDotCompose(^^, s^) . Line 3 creates ail the state vertices. For these state vertices, the node 

] . A careful analysis of the preDocCompose algodthm given later in Rgure 4,7 will show tiiat actiia]ty 
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formulas are set to be <5^( {^Iq* *o)) = ^a^^O^ <^r^(ciQ,b^) = a^(feo) - Une 3 also cre- 

ates the source event vertex (^^, s^) and the sink event vertex (t^, . These two event vertices 
are related to the source and sink of the noain machine. The rest of the event vertices are created in 
liiteS. These event vertices are projected to the main machine so that T({a,-. b^)) = . The 
algorithm is defined in terms of instantaneous paths. Hie path = a^, Oj^o^^,^-^ is an 

instantaneous path in the main machine such that the head of a path is the source or a state vertex, 
i.e. aQE{s^uV^}, and the tail of the path is the sink or a state vertex, i.e. 
^x+i^ ^^m^^m^ ' Similarly, the path = b^. by b^^^ is an instantaneous path in 
the augmented map machine such that b^^ {s^u V^} and + 1 e {V^^t^} . Given paths p„ 
and p^, the precomposition will create an instantaneous path 
<iiQ,Z)Q), <dj,/?Q>. i^Q>, (a^^^^, £?^^j) in the resultant trajectoiy formula iff paths 

tnidfixip^ and midfijcip^) &^^fy ihs^ path synchwnization prvperty. The pTop&^ 
the restrictions placed by the synchronization fiinction. 
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vertex preDotCoinpose(aQ , f>Q ) { 
if (cq, not in hash table { 

Create (a^, ^q) and put in hash table. — — Line 3 

foreach instantaneous path = Aq, a^, such that flj^^ ] e ^m^^m^ 
foreach instantaneous path = 2>q» 6^, fr^^ ^ such that + 1 ^ ^ ''^ { 
if pglhSynchProperty( m,UfiKip^) , midfi^cXp^) ) { 
<a;,^l.Ay^.X> =preDotCompose(n^^j, ft^^i ) 

Create event vertices {a^ V(i = 1 ...jc) Line 8 

Create path (<Iq, b^. (aj. &q) (^^^ *q>, ia^^x' + 

} 

} 

} 

} 

return <aQ. 6q> 

) 

bool pathSynchProperty(pfi^, pe^) { 
if {pe^ = A) return (true^ 
if (/7«^ = A) return (false) 

if ( T^i/iead(pe^))—A ) return psrthSynchProp€rty(pc^ , sufftKipe^) ) 

if ( T^(fieai£{pe^))= Aead{pe^) ) return pathSynchProperty(pe^ , suffi^{pe^) ) 

return pathSynchProperty( juj5fi^{pc^) , 

} 

Figure 4.7: Pseudo code for (he precompoi&ition ^gorithm. 

The path synchronizatioii property takes instantaneous paths and returns a Boolean value. The 
instantaneous paths pe^ and pe^ consist of only event vertices. Let us consider a path 
a^^^ ^ in the main machine and a path 2)^ ^ ^ in the map machine as shown in 

Figure 4-8- There arc two possible conditions for the path 6 . ... : 

1 . Every event vertex in the path is a free vertex, i.e. ^^{b^) = A , Vi : In diis case the preoora- 
posidon algorithm will go ahead and create the ?-path^ 

2 . There is at least one event vertex in the path that is synchronized to the raairt machine: Let us 
assume that bj is the first non-ftee event vertex in the path. Therefore, T^{bj) Ls an event ver- 
tex in the main machine. Now there are two possible conditions for the path a a : 
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2a . The event vertex Tj(^y) exists in the path: Let us assume that a^^ is that vertex, i.c, 
= ^j(^j) ' means that the synchronization condition for the vertex bj has been 
met Now recursively check the synchronization property for the paths Of^, .... and 

2b . The event vertex T^ibj) does not exist in the path: lliis means thai the synchronization 
condition for the vertex bj cannot be met In this case the precomposition algorithm will 
not create the ?-path. 



Map{s^ is v) 



Precompos'ttion 




Figure 4.8: The path synchronization property. 

Consider the example shown in Figure 4.9. The source of the map machine is synchronized to the 
sounce of the main machine. The user specified the map machine such that the event vertex b 4 was 
synchronized to the event vertex a 2 in the map machine. The map machine was augmented widi 
the dummy stale vertex db4 and the event vertex db5 so that sink of die map machine could be 
synchronized to the sink of the main machine. 




User-Specified > ^ Augmented *^ 

Figure 4.9: Example 1. An example to show the dot-composition process. 
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The result of precomposition is shown in Figure 4-10. The figure shows all the patlis generated due 
to precomposition. As an example, let us consider the instantaneous paths out of the state vertex 
Al in the main machine and state vertex B3 in the map machine. There are 6 possible combina- 
tions of instantaneous paths: 

1- A1,A1 andB3, B3! Creates the instantaneous path <Al,B3>, <Al,B3>, 

2 . Al, Al and B3, DB4: Does not create a path since synchronization for b4 is not meL 

3 , Al^ Al and B3, b4, dbS: Does not create a path since sycchronization for b4 is not met 

4, Al,a2, A2 atKlB3,B3; Creates the path (Al,B3y, <a2,B3>, <A2,B3). 

5, Al, a2,A2 and B3.b4,DB4: Creates the path <A1.B3), <a2,B3>, <A2,DB4> Since b4 is 
synchronized to a2. 

6 - Al, a2, A2 and B3, b4, db&: Does not create apath since synchronization for db5 is not met 

All state vertices are associated with action and reaction node formulas. As an example, Hie action 
and reaction node formula associated with state vertex < Al, B3> is the action and reaction node 
formuki associated with state vertex B3. AD event vertices are related to event vertices in the main 
machine. As an example, the event vertex <a2. B3> is related to event vertex a 2 in the main 
machine. 

<A2,B1> 




Figure 4^10: Example 1. Result of augmentation and precomposition. 
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4 A3 Prime Resultant lyajectory Formula 

We are iateresied in only those paths that stan at the source vertex ( j^, and end at the sink 
vertex ( t^^, , Note that some of tfie paths in the graph, in Figure 4. 10, do not end at the sink ver- 
tex (&3, db5> . The last stage in the composition process prunes away all the spuiious paths cre- 
ated by the pre-composition stage. A spurious path is defined to be a path ii) the graph which does 
not end at the sink vertex. The result of pruning is shown in Figure 4, 11, This S^'^ph is the cross- 
produci: construction of the machines imder restrictions specified by the synchronization function. 




(a2,B2) 



Figure 4,11: Example 1« Final result of dot-composhioiL 

4.5 Parallel-Composition 

A high-level view of the parallel-composition process is shown in Figure 4.12. We are given the 
trajectory formulas TTiAF^) and TTCAF^) ^. Every event vertex in these trajectory formulas is 
related to event vertices in the main machine. The parallel-composition process wiU result in the 
trajectory formula iy ( AF^ and AF^) , whose event vertices will be related to the main machine. 




Figure 4.12: High-level view of the parallel-composition process. 



1 . This section uses AF^ and AF^ instead of AF^ and AFj for convenience of notation. 
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^^m* ^frt' ^m- ^nt* ^m^ ^tt) represent the main machine. Let 
(AFJ = < V^, C/^, 5^, a^, Oj., T^> represent the trajectory formula for the abstract for- 
mula A and TTiAFf^) = ( V^, U^, s^, a^, a^, represent the trajectory formula for 
the abfsiract formula AF^ - The parallel composition will result in a trajectory formula of the fonn: 
(V. £/. r, c^, T>, where 

• V Li the set of state vertices, V ^V^x 

• U is the set of event vertices, 

U = {(u^. «P ^^a^^a and e t/^ and T,(«J = Y^(i/p} , 

• ^ is theseiofedgesj 

• J is the source, s = < j^. , 

• /is the sink, < = 

• labels state vertices wi^ action node formulas. For state vertices e and e , and 
the state vertex (v^, v^eV, the associated action node formula is 

• labels stale vertices with reaction node formulas. Fbr state vertices e and Vi. € Vi. , 
and the state vertex (v^, e V, the associated reaction node formula is 

• T relates event vertices to event vertices in the main machine. For vertices e and 
UfyG U^, and the event vertex <u^, M^eW, the associated projectian function is 

The pseudo-code for the parallel composition algorithm is shown in Figure 4.13. Hie routine is 
called as paralleiCompose(^^ s^) . Line 4 aeates all the vertices. For a state vertex, the node 
fonnukis are set to aJ^(aQ,b^) s a^(aQ) and a J^bQ) and 

o^(<"0« *o^) " ^r(^o) ^r^^oi • P^r an event vertex, we know that T^C^q) = T^i,ib^) . 
The event vertex is related to the main machine so that T((^2q, b^) = T^Chq) . The check on 
line? fissumes that the function T has been extended to state vertices- Each state vertex is 
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assamed lo be a free vertex. The recursive call on line 8 is made if either and are both state 
vertices or both are event vertices that are related to the same event vertex in the main machine, 

//Assumes that V{^2e V^) . T^(a) = A and V(^?e V^) , T(6) = A . 
vertex parallelCompose(aQ , ib^ ) { 
if (oq, not in hash table { 

Create (a^, and put in hash table. „ Line 4| 

Ibreachedge (cq, a^) { 
ibreachedg© (b^b^) { 

if (T^(fii) = T^(^i)) - -.Line 7 

b^) = parallelCompose(£i J , b^ ) „„„... Una 8 

} 

} 

} 

return (a^ b^ 

) 

Figure 4*13: Pseudo-code for the parallel-composition algorithm. 

Consider the example shown in Figmie 4.14. Event vertices in the two trajectory formulas A and B 
are related to event vertices in the main machine. 




Figure 4.14: Example 2. An es^ampie to sbow the parallel-composition process. 

The result of parallel composition of the two trajectory formulas is shown in Figure 4,15. The 
resultant graph is the cross-product of the two trajectory formulas under the i^strictions specified 
by die projection function on event vertices. All event vertices are related to event vertices in the 

86 



PAffi 151/27^ RCVD AT ni8/2005 7:43:08 PM [Eastern OayfightTm^^ 



07/18/2005 17:12 FAX 408 720 9397 



BST&Z 



@152 



main machine. As an example, the event vertex (a 2, b2) is related to the event v^ex ni2 in the 
main machine. All state veitices are associated with action and leacdon node formulas. As an 
example, the action node formula associated with state vertex (A3, B 2) is the conjunction of the 
action node formulas associated with state vertices A3 and B2, and the reaction node formula is 
the conjunction of tfie reaction node formulas associated with vertices A3 and B2. 




Figure 4wl5: Example 2. Result of paraUel-cotnposhioii. 



4,6 Trajectory Assertion 

The trajectory assertion has essentially die same forTn as the trajectory formula. Assame that 
*r^F(P) and Tf(Q) are the trajectory formulas associated with the precondidon and postcondi- 
tion respectively. The trajectory assertion is defined to be TR(P Q) = T5(P) // [T!r(fi>]^ . 
A high-level view of this construction is shown in Rgure 4.) 6. Event vertices in the trajectory for- 
mula I'lFiP) arc related to event vertices in the main machine by the total function . Event ver- 
tices in the trajectory formula ly^(Q) are related to event vertices in the main machine by tiie 
total function . The shift is effected by oaing the nextmarker function in the main machine. 
Since is a partial fimction, the composite function • is a partial funcdon. The two tra- 
jectory formnlas are augmented so as to relate the sources and sinks of the two machines and a 
variation of the dot-composition operation is used to generate the trajectory assertion. 
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Figure 4.16: High-level view of fhe shift-aitd-compose operation. 

Let TJ^{P) = {Vp, Up, Ep, Sp, tp, <y^, a^. T^) teptesent the augmented trajectory formula associ- 
ated with the precondition. Let ^(Q) = <V^ ^q>^q*^q*^q'^a^^r^g^ represent the aug- 
mented tmjectory formula associated widi the postcondition. The mirror operation reverses the 
role of the action and reaction node formulas, so that 
I'TTiQ)]^ = < V^, J7^, s^, <y^, a^, , The nextmaricer futtaion in the main machine is 
used to shift aU projections in the machine [ ( ] ^ - The result of the shift-and-compose oper- 
ation is the trajcjctcuy assertion of the form: TJliP ^ Q) = < V, 17, £. t, a^, T) » where 

• V is the set of state vertices, V £ x V^. 

• ?7 is the set of event vertices, U^(UpXU^)^iUpXV^)uiVpXU^) . 

• E is the set of edges. 

• J is the souiice, s = (5^, . 

• ^ is the smk, t = {tp. f^) . 

• labels state vertices witii action node formulas. For state vertices e Vp and € , and 
the state vertex <v^, v^gV, the associated action node formula isj 

^a«V " <y^(vp and a^(vp . 
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* labels state vertices with reaction node formulas. For state vertices v„ e V„ and v € V , 
and the state vertex (v^, the associated reaction node forrnula is 

• T relates event vertices in the trajectory assertion to event vertices in the noain machine, 

¥71 

4.7 Example 

Assume that we want to verify the bitwise-OR operation in an ALU, The abstract specification 
would define abstract elements, SA, SB, and ST. The state elements SA and SB serve as the source 
operands and ST serves as the target operand for the bitwise-OR operation. Assume that a and h 
are symbolic variables that denote the current values of SA and SB. The abstract assertion for the 
bitwiseOR operation is; 

(SAisa) and (SBis b) (ST is a[b) 

The specification is kept abstract It does not specify any tinung or implementation specific details. 
Now let's assume a specific implementation of the ALU where the source operands have to be 
fetched firom a register file and may not be immediaiely available. Assume thai both source oper- 
ands are associated with a valid signal which specifies when the operand is available. The valid 
signals have a default value of logic 0 and are asserted by the register file subsystem to a logic 1 
when tlie operand is available. The ALU computes the bitwise-OR and makes it available for stor- 
age back into the register file one cycle after both operands have been received. The block diagram 
for such an ALU is shown in Figure 4.17. Hiis is a simple example that serves to iUustrate some of 
the issues that we have encountered in our effort to verify the PowerPC architecture. 
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Aval id 
^ 

BvaJLid 
Bdatia^ 


ALU 


Tdata^ 




Register File Subsystem 



Figure 4.17: An implementatioa with a valid signal for source operands. 

There are a few interesting points to note about tills implementation: 1, The ALU might have to 
wail for an arbitrary number of cycles before either of the source operands is available, 2. The 
source operands might arrive in different orders. Figure 4.18 shows part of an execution sequence 
for the implementation. The sequence is divided into various segments each of which represents a 
bitwise-OR operation. A segment is associated with a next time point. The execution sequence can 
be obtained by aligning the start of the successive segment with the next time point of the cuixent 
segment Note that segments can be of different widths. Segment 1 exhibits a case v^ere the A 
operand arrived before the B operand. Segments 2 and 3 exhibit cases where both operands arrived 
simultaneously. Segment 3 represents the maximally pipelined case wbere the operands were 
immediately available. And segment 4 exhibits a case where the B operand arrived before the A 
operand. The goal of verification is lo ensure that the circuit correctly performs a bitwi$e-OR oper- 
atiOD under any number of wait cycles and under all possible arrival orders. 
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Next time point 



Figiii« 4.18: Part of an execution sequence for the bitw^OR operation. 

The main machine for such an iimplemeatation is shown in Figure 4,19, Each state vertex repre- 
sents a clock cycle. One or more cycles might be required to fetch the operands. This is repre- 
smted by the state vertex fetch. Multiple cycles arc required when the operands are not 
immediately available. After obtaining the operands^ the result of the bitwise-OR operation is 
available in the next cycle represented by state vertex execute. The main machine captures all 
possible segments in the execution sequence. The event vertex fetched represents the next time 
point of the segment. 




fetch eicecute 
Figure 4.19: Main machhie for the bitwise-OR operation* 

The single-sided map machine for the abstract fonnula (SA is v) is shown in Figure 4,20. The 
symbolic variable v serves as a formal argum^t. Later on, the fonnal aiguments will get replaced 
by the actual arguments. The logic value inside the state vertices represents the value of the valid 
signal for the A operand. The action node formulas associated with the state vertices are shown in 
the shadowed boxes in Che figure. The reaction node formula is assumed to be the trivially true 
node farmula. Since the operand might not be immediately available, the implementation might 
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have to wait for an arbitrary number of cycles. This is represented by state vertex wait. The oper- 
and is received in state vertex fetch. After obtaining the A operand, the implementation might 
have to wait agiun for an arbitrary number of cycles for the B operand. This is represented by state 
vertex fill. The vertices H* start and M. fetched represent the event vertices start and 
fetched in the main machine. So the source of the map machine is synchronized to the source of 
the main machine. The sink of the map machine is synchronized to the event vertex f et ched in 
the main machine, where M. fetched represents the time point where both operands have been 
received. 

M, start M- fetched 



start 




done 



Figiire 4^0: Map macfainc for (SA is v). 

Hie map machine for the abstract formula (SB is v) is shown in Hgure 4,21, The machine is the 
same as for state element S A except that the node formulas refer to the b operand. The logic value 
inside the state vertices ix^rcsents the value of the valid signal for the B operand. 



M. start M. fetched 




Figure 4^1: Map machine for ($B is v). 



92 



PAai57/27/*RCVDAT7/18l20D57:43:08PM [Eastern DayOg^^ 



07/18/2005 17:15 FAI 408 720 9397 



BST&Z 



(g]158 



Finally, the map machine for (ST is v) is shown in Rgure 4.22. The start of this machine is syn- 
chronized with the start of the main machine. This indicates that the result of the computation of 
the previous operation should be available at the start of the current operation. 



The trajectory formulas get aligned with the main machine as shown in Figure 4.23. The abstract 
formul:^ (SAfea) and (SBi$b) appear in the precondition of the abstract assertion. The cor- 
responding trajectory fonnulas ^yCSAisa) and VFiSBlsb) are derived from the map 
machines 5rfflp(SA is v) and !Map(SB is v) respectively. The formal argument v in the corre- 
spondiJig map machines are replaced by the actual ailments a and b. The node formulas in the 
map machine are treated as action node fonnulas. Action node formulas are shown in the upper 
half of the state vertex. The abstract formula (ST is a|b) appears in the postcondition. The tra- 
jectory formula [-zyCSt is a|b)]^ is derived from the map machine !W^ttp(ST is v) . The for- 
mal argument v gets replaced by the egression afb . Due to the mirror op(^nation, the node 
formuk in the map machine is treated as a reaction node formula. The reaction node formula is 
shown in the lower half of the state vertex. The trajectory formula is shifted to the nextmarker of 
the source in the main machine. 



M. start 




Figure 4*22; Map ina«*ine for (ST is v). 
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Figure 4^: Alignment of machines for bilwise-OR operation. 



The trajectory assertion for the bitwise-OR operation corresponds to the composition of these 
machines. For this example, composition anxounts to pcrfonning the cross-prodoct construction of 
the main^ SA» and SB machines between event vertices M. start and M. fetched, followed by 
the cross-product coiJStniction of the main and ST machines between event vertices M . fetched 
and M. done. The implementation mapping requires one additional piece of informauon. Notice 
that the state vertices a . fill and b . fill represent the fact that one of the operands has been 
received and the implementation is waiting for the other. When both operands have been received, 
the implementation will go ahead and compute the bitwise-OR, So in the cross-product construc- 
tion, we want to invalidate the cross-product of vertices A. fill arni B . fill. With this addi- 
tional information, tlie composition results in the trajectory assertion showci in Figure 4.24. The 
logic values in the upper half of the state verdces are the values associated with the valid signals 
for the A and B operand. The resultant control graph captures all possible orderings and arbitrary 
anmber of wait cycles. In the top path, the A operand was received before the 8 operand. In the 
bottom pathf the B operand was received before the A operand. In the middle path^ both source 
operands were received simultaneously. The result of the bitwise-OR operation is available in the 
final state vcrtCK. 

PAGE I$9I277'RCVDAT7/18/20(I57:43:08PM [Eastern Daylight Tlme]'SVR:USPTO€^^ 



07/18/2005 17:13 FAX 408 720 9397 



BST&Z 



@]160 




(Avalid is 1 ) and (Bva 1 id is 1 ) and (Adat a is a) and (3dat a Is b) 



Figure 4.24: 'trajectory assertion for bitwise-OR operation. 

4.8 Miscellaneous Issues 

In the next chapter. Symbolic Trajectory Evaluation will be used to verify the trajectory assertion 
on the circuit Symbolic Trajectory EvaJuarion uses ordered Binary Decision Diagrams (BDDs) to 
perfomi the symbolic computation. The size of BDDs is highly dependent on the ordering of Bool- 
ean variables. Therefore, the trajectory generation needs to deal with the issue of variable onteing. 
Our current tool supports a simple minded user-defined variable ordering. In the future, we need to 
incorporate more automated and efificicnt techniques for variable ordering such as dynamic vari- 
able reordCTing[71]I74]. 
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Chapter 5 

Verification Algorithms 

The verification task is to verify that the circuit fulfills the specification. This chapter concentrates 
on algorithms to perform the verification task. A more rigorous understanding of what it means to 
verify trajectory assertions will be given later in Cliapter 6. 

This chapter introduces the tem TrajectoTy Checking as a means to verify the trajectory assertion 
on a model of the circuit. The term trajectory checking has been chosen to denote its mixed heri- 
tage from model checking and Symbolic Trajectory Evaluation, The trajectory checking algorithm 
requires the ne;;Lt-state function of the entire circuiL A relaxation algorithm can be used to label the 
trajectory assertion with feasible dicuit states. There are two forms of trajectory checking: set- 
based and lattice-based trajectory checking. Lattice-based trajectoiy checking can be viewed as an 
approximation of the set-based version. The lattice-based approach is coniputationally efficient but 
somewhat pessimistic. It can therefx>re yield false negative resuhs, where a correct circuit foils the 
verification* 

Trajectcwy checking requires the next-state function for the entire circuit This can t)e very expen- 
sive for conqilex systems such as processors. One way of overcoming this limitation is Symbolic 
Trajectoiy Evaluation. Symbolic Trajectory Evaluation (STE) can be viewed as a modified form of 
sjrmbolic simulation that computes the next-state function on-the-fly and only for that part of the 
circuit required by the specificdtion[8]. STE has been used in the past to verify a limited form of 
the trajectory assertion. This chapter discusses extensions to STE to deal with our generalized 
model of trajectory assertions. 

5.1 Related Work 

Informally, a trajectory is sequence of states that represents an acceptabb bdiavior of the circuit 
A mon: rigorous definition of a trajectory will be given later in Chapter 6. Seger and Bryant intro- 

97 

PAaE162/2?rRCVDAT7/18120(»7:43:08PM [Eastern Oayip 



07/18/2005 17:14 FAX 408 720 9397 



BST&2 



@163 



duced the term trajectory assertionElS], A simple trajectory assertion was defined in the form of an 
implication, i.e., antecedent implies the consequent. The antecedent and consequent were trajec- 
toiy formulas that used the next-time operator to define restrictions on circuit nodes for a finite 
duration of time. The sequence and iteration constructs were used to create more complex trajec- 
tory assertions. In effect, their simple trajectory assertion was a single sequence of state vertices 
labelled with action and reaction node formulas. The iterations constmct augmented the single 
sequence with a limited set of loops. They, however, did not allow nested or interacting loops. Our 
trajectory assertions are aibitraiy control graphs with state vertices labelled with action and reac- 
tion node formulas, 

A detailed description of related work in model checking and Symbolic Trajectory Evaluation was 
presented in Chapttt^ L 

5,2 Terminology 

The mathematical form of the tr^ectory assertion was introduced in Section 4.6. The trajectory 
assertion was defined to be a control graph with action and reaction node formulas on state vertices 
and a function to relate event vertices to the main machine. For the purposes of this chapter, we can 
ignore the event vertices (except for the source and sink vertices) and their relation to the main 
machine. This can be done by taking a transitive closure of all the event vertices except for the 
source and sink. For the purposes of this chapter, a trajectory assertion can be assumed to be a 
tuple of the form; G = < V, J7. £, 5, r, a^, . where 

• < K I/, 5, r> is a control graph, where U = {s, t} , 

• labels staic vertices with action node formulas. 

• labels state vertices with reaction node formulas. 

In this chapter, we shall refer to the set W as the set of all vertices, W = Vu {s} u {r) . 
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53 Set-Based IVajectory Checking 

Trajectory checking uses a relaxation algorithm to label the trajectory assertion with feasible cir- 
cuit states. The set-based approach operates on a set-based model structure of the circuit and a set- 
based interpretation of the trajectory assertions. 

5.3.1 Set-Based Model Structure 

Assume that is the set of node elements in the circuit The. set of node elements is the set of 
extema] inputs, outputs, and intemal nets in the circuit The set of node assignments is defined to 
be ^ = {0, 1 , where m = |A^^ . The circuit is nK)deled as a tuple: <JV, ti> , where r| is the 
circuit excitation junction, i\:N—> 2^. The excitation function is defined in a non-traditional 
way. Given the cuirent node assignment, the ^citation function expresses constraints on the set of 
next node assigrmwnts. Since the value of an input is controlled by the external enviromnent, the 
circuit itself does not impose any constraint on the inputs. The circuit, however^ does impose con- 
straints on the outputs and intemal state elements. The excitation function expresses the con- 
straints on the set of node assigrmients after the circuit has reached a stable state assuming all 
external inputs axe held fixed untQ the circuit has reached that stable state. 

As an example, consider an inverter realization. The set of node assignments is 
N = {00, 01, 10. 11} , where the left bit represents the logic value on the input node and the 
light bit represents the value on the output node of the inverter. The excitation function for the 
inverter is shown in Figure 5.1. Consider the case of the input currently at logic 0 and output at 
logic 1 . Tliat is represented by the node assigimiOTt 01 in the figure. At the next tune instant the 
output is constrained to be at logic 1, whereas the input is unconstrained. That is represented by 
transitions from node assignment 01 to node assigruneats 01 and 11. 
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Figure 5.1: Set-based excitation fdnction f6r an invcrtci; 

The set-based model structure for a circuit is a tuple of the form: C = {N^S)^ where N is the set 

of node assign ments and 5 is the model excitation funcdoru S : 2^ — > 2^. The circuit excitation 

function is extended to fonn the model excitation function in the following way: 

5{A) = LJ Tl(«) , where A siiV. 
A 

53.2 Set-Based Trajectory Assertion 

In the set-based model, a node formula is represented by a set of node assignments. The set of 
node assignments corresponding to a node formula F , written Set{F) , is defined recursively, 

• Set(true) = TV 

• Set (n . Is 0 ) 1 s the subset of N containing 2™ ~ ^ node assignments having the position as 0. 
Similarly Setin^is 1) is the subset of N containing 2"*~ ^ node assignments having the fi^ 
position as 1 . 

• JetCQ^F) = ^ and Setil-^F) = Sct(F) 

For a vertex v € V, we will refer to the set 5et(<J^(v)) as the set of action node assignments and 
the set 5«t (c7^(v)) as the set of reaction node assignments associated with the vertex v . 

We can classify trajectory assertions into three categories in increasing order of expressiveness and 
complexity: 1) Oblivious 2) Adaptive and 3) Prescient. Consider a vertex v in the trajectory asser- 
tion and pick any two vertices v. and Vj such that (v, v.) e E and (v, v^) e £ . An oblivious tra- 
jectory assertion has the restriction that Stt[aJ^v>)) n Stt{<sJ,Vj)) = 0 . In other words, the 
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next stimulus or constraint imposed by the envjronraeni defines a unique vertex in the trajectory 
assertion- An adf?)tive trajectory assertion has the restriction that either 
^«(cy^(v,.))njet(0^(vy)) = 0 or Set(a^iv.))nSet(o^(vj)) = 0 . The next stimulus 
and the next circuit response together define a unique vertex in the trajectory assertion. This can be 
viewed as a lookahead-1 trajectory assertion since it requires knowledge of the next ciicuit 
response, A prescient trajectory assertion does not place any such restrictions. Such a trajectory 
assCTtion requires knowledge of the circuit response in the fiiture to determine the next vertex in 
the graph. 

In this chapter, we limit ourselves to algorithms to verify oblivious trajectory assertions. A more 
rigorous definition of what it means to verify presdent trajectory assertions will be given later in 
Chapter 6. Possible extensions to the algorithm to deal with ad^ve trajectory assertions are pre- 
sented as future work in Chapter 9. 

The new section defines a relaxation algorithm that can be used to verify oblivious assertions with- 
out explicitly enumerating all paths in the graph, 

533 Set-Based Relaxation Algorithm 

The relaxation algorithm uses, the model strucmre to compute the defining trajectory for an oblivi- 
ous trajectory assertion. Informally, a trajectory is sequence of stares that represents an acceptable 
behavior of the circuit A more rigorous definition of a trajectory will be given later in Chapter 6. 
The defining trajectory is the ^uenoe of maximal set of states that satisfy the action node formu- 
las. The verification task is to compute the defining trajectory and verify that each of the defining 
trajectory satisfies the reaction node formulas. The relaxation algorithms computes the dcfinirug 
trajectory m terms of defining trajectory labels on each vertex in the trajectory assertion. The 
defining trajectory labels map each vertex in the trajectory assertion to a set of node assignments, 

The pseudo-code for the set-based relaxation algorithm is shown in Figure 5.2. Line 4 mitializes 
the defining trajectory labels to be the empty set for all vertices, line 5 initializes the defining tra- 
jectory label for the source vertex to be the set of all node assignments. The relaxation algorithm 
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starts from the source vertex and works its way lo the sink vertex in a deprh-first manner. Line 10 
computes the effect of vertex w on the vertex , where {w, w^) is an edge in the control graph. 
The temporary variable Y stores the set of node assignments resulting firom applying the excitation 
function on the defining trajectory label on vertex w and intersecting that with the set of action 
node assignmenrts on vertex w^.. Lines 11 and 12, in effect, compute the least fixed point of the 
defining trajectory label on vertex . The least fixed point computation corresponds to perform- 
ing a reachability analysis on the set of node assigimients. For the verification to succeed, the 
defining trajectory label on a vertex should be contained in the reaction node assignments for that 
vertex- 



II W ^ Vu{5}u{f} 
verify( Cr){ 

foreach(we W) k(w) = 0 Line 4 

K( j) = N Line 5 

relax(G, s) 

} 

rTelax(G,w){ 

foreach ( (w, e £ ) { 

Y = 5(K(w)) n jc£(<y^(w.)) Line 10 

\f(YiK(Wi))[ Line 11 

k(w^) = K(w^) u Y Line 12 



else "verification failed" 

} 

) 

} 

Figure 5*2: Set-based relaxation algorithm for oblivious trajectory assertions. 

As an example, consider a circuit for a modttlo-3 counter. The state diagram for a modttIo-3 
counter is shown in Figure 53. The state diagram has 4 states A, B, C and D which are encoded in 
the circuit as 00, 01, 10, and 11 respectively. Assume that A is the start state. The circuit has an 
active high re.^et signal. The transidons in die state diagram are labelled with the reset signal 
value. When the reset signal is at logic 1, the circuit resets into the start state A. When the 
reset signal is at logic 0, the counter performs a modulo-3 count i-e., transitions through the 
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States A, B, A . Apart from the exiernal input reset signal and two internal state bits, let us 
assume that the circuit has another external input in signal and an output out signal. Assume that 
the output is the AND of the two state bits and the input in signal. Thus when input in is 1, out 
will be 0 for states A, B, C and 1 for state D. 

1,0 



D 
11 



B 
01 



. c 

10 



Figure 53: State diagr^ for a niodiiIo-3 counter* 

Let us assume that we are trying to verify the trajectoiy assertion shown in Figure 5.4. The action 
node formulas are shown in the upper half and the reaction node formulas are shown in the lower 
half of the shadowed box. The trajectory assertion is stating the following property: If the circuit is 
reset for one cycle, followed by maintaining the reset signal to logic 0 for an arbitrary number 
of cycles, then in the next cycle when in goes to 1, die output out should be logic 0, i.e., the cir- 
cuit should be in states A, B, or C. 




Figare 5^: l^Jectory assertion modulo-J counter* 

There are 5 node elements in the circuit, namely the reset signal, in signal, the 2 internal state 
bits and out signaL Therefore, the set of node assignments is 

= (0, 1 }5 = {00000 mil}, whCTB the leftmost bit is the logic value associated with 

the reset signal, the next bit is the logic value associated with the in signal, the next 2 bits are 
the logic values associated with the internal state bits and the rightmost bit is the logic value asso- 
ciated with the out signal. The set-based circuit excitation function can be easily derived from the 
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State diagram in Figure 5.3. As an exampte, if the current reset is 0, in is 0, and the current state 
i$ A(00), then the next inputs are unconstrained, the next state is constrained to be B(01) and next 
output is constrained to be 0,i.e. 7i(00000) = {00010, OJOIO. 10010, 11010} . The circuit exci- 
tation function will be extended to form the model excitation function 5 . The node formulas in the 
trajectoiy assertion in Figure 5.4 are interpreted as a set of node assignments. As an example, the 
set of node assignments associated with the action node formula on state vertex V2 is the set of 
node assignments where ihe reset and input signals are at logic 0, i.e., 
Jct(a^(v2)) = {00000,00001,00010,00011,00100,00101,00)10,00111} . 

The relaxation algorithm will compute the defining trajectory labels for state vertices in the trajec- 
tory assertion, L&t us first consider the vertex VI. The defining trajectory label for the vertex VI is 
computed as follows: 

K(vi) = 5(N)nSct{<j^{vi)) 

= {lOOOO, 10010, 10100, 10110} 

The defining trajectory label for the vertex V2 is computed as follows: 

K^(V2) = 5(K(Vl))njct(<5^(V2)> 
= {00000} 

icV2} = KUv2)Lj[6(Kl(V2))n5<t(<y^(V2))] 
= {00000} u {00010} = {00000, 00010} 

k3(V2) = K2(v2)u[S(K^(V2)in5gt(cf^(V2))] 
= {00000, 00010} u {00100} 
= {00000. 00010, 00100} 

Theset K^(V2) represents the least fixed point since k3(v2) = K^(V2) . Therefore, the defin- 
ing trajectory hibel for vertex V2 is k(v2) = K^(y2) . The least fixed point calculadoo on the 
self loop on state vertex V2 amounts to performing a reachability analysis, i.e. the circuit states 
that are reachable in vertex V2. Thus the reachable states in the circuit are A(00>, B(01) and C(1 0). 



104 



PAGE 1681277*RCVDAT7/18/2fl057:43:08PM [Eastern DayfightT^^^ 



07/18/2005 17:15 FAX 408 720 9397 



BST&Z 



21170 



The defining trajectory label for the vertex V3 is computed as follows; 

k1(v3) = 5(K(Vl))nJ«t(a^(v3)) 

s= {01000, 11000} 
kH^3) = KHv3)u(5(K(v2))n5et(a^(v3))) 

= {Olooa 11000} u {01000. 01010, 01 100. nooa iioio. iiioo} 

= {01000,01010,01100, IIOOO, IIOIO. 11100} 

Therefore, the defiaiog trajectory label for vertex V3 is k(v3) = K^(v3) . The trajectory asser- 
tion will be reported to be true since the output signal is 0 in all the node assignments in k(V3 ) . 
In other words K(V3) c Jct{o^(y3)) . 

5A Lattice-Based Trajectory Checking 

Lattice-based trajectory checking can be viewed as an approximation of the set-based approach. 
The logic set is extended to the ternary domain, {0, 1 , X} . The logic X denotes an unknown and 
possibly indeteiminate logic value. The logic values are assumed to have a partial order with logic 
X lower in the partial order than botJi logpc 0 and logic 1 as shown in Figure 5.5. The partial order 
operator C is defined as follows: a C « for any ternary value a, X C 0 and XU I. 

0 1 
X 

Figure S3i Partial order for Icigie 0, 1^ and X. 

We say that two ternary values a and b are conq)atible, denoted a^-b, when there is some tematy 
value c such that c and c.ln other words, two values are compatible unless one is 0 and 
the other is 1 . 

We can define two operations, the least upper bound and greatest lower bound, over ternary values. 
The symbols U and PI denote the least upper bound and greatest lower bound operations respec- 
tively. Assuming two ternary values a and fc, the least upper bound and greatest lower bound oper- 
ations are defined as follows: 
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aUb 


0 


1 


X 


aUb 


0 


I 


X 


0 


0 




0 


0 


0 


X 


X 


1 




1 


1 


1 


X 


1 


X 


X 


0 


1 


X 


X 


X 


X 


X 



Note that the least upper bound is defined only under the case that a and b are compatible. The - in 
the table for a U ^ denotes incompatible cases where the least upper bound is not defined. 

5-4.1 Lattice-Based Model Structure 

The set of node assignments is extended to {0, 1, X}^ , where m - ^Nj^ . The elements of the set 
define a lattice. A top element T is introduced to complete the lattice. Therefore, the set of node 
assignments is iv = {0, 1, xy^ u T . The elements of the set iv^ define a lattice C ] , with 
as the boaom element and T as the top element. The partial order in the lanice is a pointwise 
extension of the partial order shown in Figure 5.5. The compatible, least upper bound, and greatest 
lower bound oi^crators are also extended pointwise. The least upper bound of two lattice elements 
A and B is defined to be the top element when A and B are not compatible with each odier. The 
complete lattice for m = 2 is shown in Figure 5.6. As an example, OX C 01 , which should inter- 
preted as the lattice element OX has less informatioti than the lattice element 01. Also 
oxuxi = o],o;i:u IX = TandOOnai = OXi 

00 01 10 n 

KXXI 

ox XO XI IX 
XX 

Figure 5.6: Complete lattice for 2 node elements. 

The lattice-based formulation can be viewed as an approximation of the set-based formulation. 
The relation between symbols and operators in the two fomialations is shown in the table below. A 
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set is approximated by an element of the lattice. As an example, the set {00, 01 } would be accu- 
rately jepresented as 00 H 01 = OX. However, the set {01, 10) would have to be approximated 
to 01 n 10 = XX. 



Set 


Lattice 




AG N 


N 


Xm 




T 




□ 


n 




u 


n 



The lattice-based model stnicture for a cdicuit is a tuple of the form: C = <Ii^, C ]» 5> , where S 
is the model excitation function, 5:N~>N and 5(T) = T . The model excitation function is 
required to be mwiotone over the partial order in die lattice, i.e if A C ^, then 5(A) C 5(B) . 
Ti« monotonicity requirement is consistent with our use of information content If a function is 
monotone, we cannot gain any information by reducing the information content of the alignments 
CO the function. In other words, changing some signal from binaiy values to X will either have no 
effect on the excitation, or it wjj) change some binary value to X. 

Again, consider an inverter realization. The set of node assigrunents and the associated lattice is 
shown in Figore 5.6, where the left bit represents the logic value on the input node and (he right bit 
represents the logic value on the oiitput node of the inverter. The lattice based excitation function 
for the inverter is shown in Figure 5.7. Consider the case of the input currently at logic 0 and out- 
put is at logic 1. That is represented by lattice element 0) in the figure. At the next time instant, the 
output is constrained to be at logic 1, where as the input is unconstrained. That is represented by a 
transition &om lattice element 01 to lattice element XI . 

Q 





00' ^ 10 

Figure 5.7: Lattke-based excitation function for an inverter. 
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5.4.2 Lattice-Based Trajectory AssertiotJ 

In the lattice-liased mcxleU a node formula is represented by an element of the lattice. The 
resijicted fonn of the node formula ensures that it can be represented by a unique latiice elemenu 
The lattice elejnent corresponding to a node formula F, written Lat(F) , is defined recursively: 

• Lat(true) = X"^ , 

• Latin ^ is 0) is an element of the lattice widi the ^ position in die element being 0 and the resc 
of the positions being X's. Latin, is I ) is an element of the lattice widi the position being 1 
and the rest of the positions being X's. 

• Lat(F^ and Fj) - Lat^F^) U Lat^F^l • 

• Lat{0-*F) = and -*F) = Lat(F} . 

Foravertex V c: V, we will refer to the element £flt(a^(v)) as the action lattice element and the 
element Lat{G^(v)) as the reaction latdce element associated with the veitex v. Observe that 
the above construction is exact The approximation in the lattice^based method is due to the great- 
est lower bound operation tlxat will be used in the relaxation algorithm. 

Again, we will restrict ourselves to oblivious trajeccoiy assertions. Consid^ a vertex v in the tra- 
jectoiy assertion and pick any two vertices v^. and v^. such that (v. v^.) e E and (v, v^) e £ . In 
the lattice domain, the restriction for an oblivious trajectory assertion translates into 
Lat{a^{v,)) U Lai{a^(vj)) = T . The next section defines a lattice-based relaxaticm algorithm 
that can be used to verify oblivious assertions without explicitly enumerating all paths in the 
graph. 

5.4.3 Lattice-Based Relaxation Algorithm 

The relaxation algorithm computes the defining trajectory in tenns of defimng trajectory labels on 
each vertex in the oblivious trajectory assertion- The defining trajectory is the unique weakest tra- 
jectory that satisfies the action node formulas. The defining trajectory labels map each vertex in the 
trajectory assejiion to a lattice clement, k :W 
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The pseudo-code for the lattice-based relaxation algorithm is shown in Figure 5.8, Line 4 iniiial- 
izes the defining trajectory labels Co be the top lattice element for all vertices. Line 5 initializes the 
defining trajectory label for the source vertex to be the bottom lattice element The relaxation algo- 
rithm starts from the source vertex and works its way to the sink vertex in a depth-first manner. 
Line JO computes the effect of vertex w on the vertex w- , where (w, w^) is an edge in the control 
graph. The temporary variable Y stores the lattice element resulting from applying the excitation 
function On the defining trajectory label on vertex w and taking the least upper bound with the 
action lattice element on vertex w . . Lines 1 1 and 12, in effect, compute the greatest fixed point of 
the defining trajectory label on vertex w^. The greatest fixed point computation corresponds to 
performing an approximate reachability analysis. For the verification to succeed, the defining tra- 
jectory label on a vertex should be the same or higher in the partial order than the reaction lattice 
element for that vertex. 



//W = VkjU 
verIfy(C){ 

foreach(we W) k(w) = T Line 4 

x(s) = X"* Lines 

reiax(G. s) 

} 

relax(C, w) { 

foreach ( (w, w^). e £ ) { 

Y = 6(K(w)) U XatCa^Cw-)) Une 10 

if( y a kiw^))l Linen 

K(iv-) t= x:(w.) n y Line 12 



If ( K(iv.) D i:at(a^(w.)) ) relax(G. u/.) 
else 'S/^rfiqation failed" 

} 

} 

} 

Figure 5*8: Lattice-based relaxatioa algorithm for obiivioas tr^ectory assertions. 

The laltice-based approach is computationally moi^ efficient than the set-based approach. The rear 
son is that sets can now be represented by a single lattice element The logic value X is used to 
model nondeterminism in the system. The lattice based approach, however, can lead to a pessimis- 
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tic verification. A pessimistic verification can generate a feJse negative, i.e., a conect circuit can be 
reported to be incorrect. 

Consider the example of the modulo-3 counter that was introduced in Section 5.3.3. The set of 
node assignments is W = { 0, 1, X}^ u T . The elements of this set define a complete lattice. The 
model excitation fiinction can be derived from the state diagram in Figure 5,3, As an example, if 
the current reset is 0, in is 0, and the cunent state is A(00), then the next input is unconstrained, 
the next state is constrained to be B(01), and the next output is constniined to be 0, i.e., 
5((K)000) = A'XOIO . The node formulas in the trajectory assertion in Figure 5.4 will be inter- 
preted as lattice elements. As an example, the lattice element associated with the action node for- 
mula on state vertex V2 is Lat(o^{V2))- - OOXXX . 

The relaxation algorithm will compute the defining trajectory labels for state vertices in the tr^ec- 
tojty assertion. Let us first consider the vertex VI. The defining trajectory label for vertex VI is 
computed as follows: 

K(V1) = SiJr)ULatia^(Vl)) 
- lOXXO 

The defining trajectory label for the vertex V2 is computed as follows: 
k1(V2) = 5{K(vi))UXaf{a^(V2)) 

- XXOOO U OOXXX = 00000 
k2(V2) ^ k1(V2) n [8(ickv2)) U LatiCjVZm 

00000 n (xxoio u ooxxx) ^ oooxo 

x:^(v2) ic2(v2)n[S(ic2(V2))U£at(aJV2))] 

= 000X0 n (xxxxx u ooxxx) = ooxxx 

The lattice element i.^(V2) represents the greatest fixed point since K^(V2) = K^(V2) . 
Therefore, the defining trajectory label for vertex V2 is ic(V2) = x?QJ2) . Note that the lattice- 
based approach has erred on the side of pessimism and has approximated the reachable set of 
states by the laitice element XX, The lattice element XX corresponds to the states A, B, C, and D. 
The lattice based approach calculates the reachable lattice element to be XX even though the set- 
based approach has revealed that the reachable states are only A, B, and C. 
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The defining trajectory label for vertex V3 is con^)uted as follows: 

k'{V3) = S(K(V1)) U jL<rt(a^(V3)) 

= XXOOO U XIXXX = ^TJOOO 

k2(V3) = Kl(V3)n[5{K(V2))UXat(G^(V3))] 

= xiooo n {xxxxx u xixxx) = xixxx 

The trajectory assertion will be reported to be false since k(V3) is lower in the partial order than 
the reaction lattice elermeni on state vertex V3- In other words k(V3 ) 3 Xaf (a^(V3)) . In other 
words die latticcr-based approach reports a correct circuit to be incorrect. 

Tlie above example has revealed a shortcoming of the lattice-based approach. The lattice-based 
approach errs on the side of pessimism for the sake of efficiency. A reason for this pessimism) is the 
greatest lower bound operator. The greatest lower bound operator n oti lattice elements approxi- 
mates the union operator u on sets. In our example, the reachable set of states {00, 01, 10} had 
to be approximated by the lattice element 00 PI 01 R 10 = XX . The greatest lower boimd opera- 
tion is used to obtain a monotone excitation function. Also, the greatest lower bourtd is used on 
line 12 of Hie relaxation algorithm in Figure 5.8. 

The set and lattice-based approaches can be viewed as two ends of a spectrum. At one end of die 
speccnim is the set-based approach that leads to an accurate verification but is computationally 
complex. At the other end of the spectrum is the lattice-based approach that is computationally 
efficient but can lead to a pessimistic verification. The reason for efficiency is that a set can be rep- 
resented by a single lattice element The efficiency is obtained at the price of a pessimistic verifica- 
tion. A pessimstic verification can generate a false negative, i.e., a correct circuit is repotted to be 
incorrect. A pessinrustic verification, however, will never generate a false positive, i.e., the verifica- 
tion will never report an incorrect circuit to be conecL 

5.5 Symbolic Trajectory Evaluation 

Trajectory checking requires the model excitation function for the entire circuit. This can be v^ 
expensive. As an example, it woold be impossible to obtain tiie complete excitation function for 
complex processors. One way of overcoming this limitation is to use a simulation-based verifica- 
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tion strategy. A simulation-based verifier computes the excitation function on-tJie-fly and only for 
that part of the circuit required by the trajectory assertion. Symbolic TVajectoiy Evaluation (STE) 
is an extension of symbolic simulation that provides a concrete way of verifying the desired sys- 
tem behavior over a period of tirae[8][12)[l8J, A description of the ternary symbolic representa- 
tion used in STE is given in Section 5.5. 1. 

Oblivious trajectory assertions can be classified into three categories in increasing order of gener- 
alissation and complexity: 1) Single Sequence 2) Acyclic and 3) Gcnemlized. Hie control graph 
associated with a single sequence trajectory assertion has a linear sequence of vttticcs. An acyclic 
tr^ectoiy assertion has a directed acyclic control graph. And the generalized trajectory assertion 
has any arbitrary control graph. In earlier work, STE has been used to verify single sequence tra- 
jectory asseirtions[8][l2}. A brief description of earlier woric is given in Section 5.5.2. We have 
extended STE to verify generalized trajectory assertions. Our extensions for acyclic and general- 
ized trajectory assertions are described in Section 533 and Section 5.5.4 respectively. 

5.5.1 Ternary Symbolic Representation 

STE represents a ternary value, ye {0, l.X} , with a "dual rail" encoding, (y\y^) , where 
3^, € {0, 1 } . The symbols and refer to the higji and low rails of the encoding. The 
encoding for the ternary value is given below. The encoding (0» 0) serves as a don't care. 

0 0 1 

1 1 0 
X 1 1 
Z> 0 0 

Hie encoding can be extended into the symbolic domain. In the symbolic domain^ Boolean encod- 
ings are defined as a function over a set of symbolic variables. The Boolean encodings (y^ y') 
denote a ternary symbolic function y . TTie partial order, compatible, least upper bound, and great- 
est upper bound operations are extended into the symbolic domain. Let a and b represent two ter- 
nary symbolic ftmctions with Boolean encodings (a^ a^) and {b\ respectively. The partial 
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order aZ b is defined as the Boolean function a^-b^-i-a^ b^-^a^ -b^. Compatibility of two 
ternary symbolic functions a - ^ is defined as the Boolean function b^ + b^ . 

The least upp^ bound operator aUb is defined in terms of the Boolean encodings as 
(a'* • b^, -b^), A Boolean OK function defines the case where die two ternary symbolic func- 
tions, a and b t are compatible with each other. The greatest lower bound operator aU b is 
defined in terms of the Boolean encodings as (a* + i^, + b^) . 

As an example^ consider a = (u, u) and b = (v, v) , where u and v are Boolean symbolic 
variables. The least upper bound is a U b = (u © v. u • v, u - v) . The table below shows the 
cases due to all possible assignments to the Boolean variables u and v. The shaded rows represent 
the case where a and b are not compatible with each othec 



u 


V 


aUb 


a~b 


0 


0 


0 


1 










1 r, > 1 > >r 1 , • 








1 


1 


1 





We can define a ternary existential quantification operator ^ a for the teniaiy symbolic function a 

V 

over the set of symbolic variables V, The Boolean encodings for the ternary existential quantifica- 
tion operator is defined to be the existential quantification of the Boolean encoding, i.e., 

Ky J y ^ V 

As an example, consider that a = (u, u + v) , Then 3^ = (^i. 1) > i-e., the ternary existential 

V 

quantificaticm is restricted to the values 0 and X. The table below shows the cases due to all possi- 
ble assignments to the Boolean variables u and v. 



u 


V 


a 


* 

V 


0 


0 


0 


0 


0 


1 


0 


0 


1 
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X 


1 


1 


1 


X 
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A ternary symbolic function is extended pointwise to represent a symbolic elemeni in a lattice. All 
the operators are extended pointwise to operate on these symbolic lattice elements. 

5-5.2 Single Sequence Trajectory Assertion 

The general form of a single sequence trajectory assertion is shown in Figure 5,9. The trajectory 



STE uses a variation of the trajectory checking algorithm shown in Figure 5.8 to verify single 
sequence trajectory assertions. All the lattice operations are extended into the symbolic domaii)- 
Instead of precomputing the entire model excitation function 5 , the simulator is used to obtain the 
next-state of the circuit at each step of the iterarjon. The defining trajectory labels are stored as 
symbolic values on nets in the simularor. The essence of the STE algorithm is captured m the algo- 
rithm shown in Figure 5.10, The global variable Q represents net values in the simulator. All net 
values are initialized to the logic valne X STE maintains two global Boolean functions OK^ and 
OKp defined over symbolic variables. The global functions are initialized to 1 (the Boolean func- 
tion that is always true). SIB updates the net values and the Boolean functions for each state vertex 
in the single $equeiK:e trajectory assertion. Line 10 computes the excitation for the circuit and 
stores it in the temporary variable Y, The use of SimiQ) represents that the simulator is used to 
obtain the excitation for the circuit. Line 11 computes the defining trajectory Label as the least 
upper bound of the excitation and the action lattice element, and updates the net values with tbe 
defining trajectory label. The function OK^ on line 12 maintains the condition under which the 
excitation is compatible with the action lattice elemrait. As an example, assume that the simulator 
computes the excitation for a net to be the symbolic value u and the action node formula specifies 
that the same net should be asserted to the symbolic value v. The fimction OK^ would be u © v 
and the net value would be (u © v) ? u : i) - The function OKj^ maintains die condition under 
which the reaction node formulas are satisfied Rnally, STE computes the OK function which 
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inforroiilly says that the trajectory assertion holds for the circuit if either the action node formulas 
are unsatisfiable or the reaction node formulas are satisfied. 

verify(G){ 
Q = X" 

STt_Sequence( G ) 

OK = OK^ + OK^ 

) 

STE_&quenc6(G) { 
for{i = 1 to Jt){ 

Y = Sim(Q) Une10 

Q = YU Latio^iv^)) Line 11 

OKy^ = OKj^ ' [r ^ Xat(a^(v.))l Line 12 

) 

} 

Figure 5.10: The STE algorithm for single sequence trajectory assertions. 

An interesting property of the single sequence algoiithm is that the symbolic computation is per- 
formed on only those variables that appear in the trajectory assertion. Unlike odier symbolic cir- 
cuit verlfiers[6], STE does not introduce extra variables to represent the initial state or external 
input values. 

5.53 Extensions for Acyclic TVajectory Assertion 

An acyclic trajectory assertion can be verified by enumerating all the paths from source to sink and 
using STE separately on each path. There can, however, be an exponential number of paths in a 
graph. We use path variables to encode the graph and verify all paths in one single run of the sim- 
ulator. The algorithm for encoding an acyclic trajectory assertion is shown in Figure 5.11. The 
encoding is specified in terms of a Boolean expression, Tatfi{w) , defined over the path variables, 
which specifies all possible conditions under which there exists a path from the source to the ver- 
tex w. The encoding is performed in topological order of the vertices. Line 5 creates 
riog(rf(w))l number of variables for every vertex w with outdegree d(w) . Line 8 accumulates 
die path expressions on tfte vertices to compute the path function. 
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encodeGraph(G) { 

f6reach(wG W) Tatfi{w) = 0 
TatfiU) = 1 

Toreach we W \n topological order { 

Generate flog(rf(w;))1 new variables Line 5 

foreach ( (w, w^) e E){ 

Let !£rtc(w, w^) represent encoded expression for edge 
iPatfUw^) = tPatB{w^) + !Pathiw) • ^nciw, w^) Line B 

] 

) 

} 

Figure Algoridum for encoding an acydic trajectory assertion. 

Consider the control graph shown in Rguie 5.12. The edges are assodaied with encoded expres- 
sions. As an example, two path variables are created at the source to encode the three outgoing 
edges. The encoded expression associated with the edge from the source to vertex A is 
£nc(start, A) = Pq - pj , The vertices arc assodated with the path function- As an example 
fpatfi(-£,) - p , • p2 + Pq • An assignment to the path variables to sadsfy this function indicates all 
the paths liom source to vertex e. 




Figure 5,12: Symbolic Encoding of acydic trajectory assertions. 

STE has been extended with a conditional simulation capabiUty. Conditional simulation allows 
STE to compute the next state under some specified Boolean condition. Under the condition, the 
simulator comfHites the next state. Under the complenaent of the condition, the simulator maintains 
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the previous state of the circuiL The extensions to the STE algorithm to verify acyclic trajectory 
assertiotis is shown in Figure 5.13. The routine STE_SequenceO presented carher should be 
replaced by the routine STE_AcyclicO- The routine STE^AcydicO computes the vertices in topo- 
logical order. A topological order for the graph in Figure 5.12 is start. A, D, B, E, C, F, G, done. 
The path function serves as constraints for updating the net values, OK^ and OKj^ . 

STE_Acycnc(G){ 

foreach state vertex v in topological order { 
Y = Sim{Q) 

Q = (2atk{v) lYU Lati<3^{v)) : Q 
OKj^ = OK^ - ( gatji(v) + iy-Xflt(g^(v))l] 
OK^ = OKj^ - [!Batfi{v) + [Q 3 LatiG^iv))]] 

) 

} 

Fisare 5.13: The STE algorithm for acyclic tr^cctocy assertioiis. 

Apart from serving as constraints for conditional simulation, the path variables serve another use- 
ful purpose. In effect, die above algorithm is performing a greatest lower bound computation at all 
vertices with multiple incoming edge.s. The path variables enable a symbolic greatest lower bound 
operation, thus avoiding the pessimism with the greatest lower bound operation on a pure scalar 
ternary model. 

The symbolic computation in the acycUc version of STE is performed on both the variables that 
appear in the trajcciojty assertion and the path variables. Since the path variables are used to 
encode the trajectory assertion, the total number of variables that are symbolically manipulated is 
still determined solely by the trajectory assertion. The number of additional path variables intro- 
duced is ]^ flog(d(vv))] . 

5SA Extensions for Generalized 'n-sgectory Assertion 

Seger and Bryant extended STE to deal with single sequence trajectory assertions augmented with 
a limited set of loops[18]. In particular they could deal with a loop with a linear sequence of verti- 
ces as shown in Figure 5.14. The cycle Vj^, V|, v^^ ...» Vjj._ v^^. represents a loop with a linear 
sequence of vertices. 
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Figure 5.14: A loop vith a liaear sequence of vertices. 

Assume that Q represents the entry-level defining trajectory lab^ on vertex due to the edge 
(vy, Vj^) . The algorithm for computing the defining trajectory label for vertex due to the single 
sequence loop SSL is shown in Figure 5,15, The graph SSL^ , In line 5, is the single sequence tra- 
jectory assertion, shown in Figure 5.9, chained after breaking the cycle in SSL, The algorithm 
computes the greatest fixed point of the recursive equation 
g^+l = nSTE.SequenceCJSL-^) . The routine STEjSequenceQ was defined in 
Figure 5.10. 

GFP_Sequence(55L ) { 
F = T 

while {P^Q){ 
P = Q 

STE_Sequence(55L^ ) ..... Line 5 

Q = PUQ 

} 

} 

Figure 5.15: Cumputing greatest fbced point fbr sin^e sequence loops- 

We have extended STE to deal widi generalized trajectory assertions. Our STE algorithm to veii^ 
generalized trajectory assertions is shown in Figure 5.16. Line 2 identifies the strongly connected 
components in the tmjectory assertion. A strongly connected component is a maximal set of verti- 
ces V"^ V such that for every pair of vertices Vj g V"andv2e V", there exists a path from Vj^ to 
V2 and a path ftom V2 to Vj . In othar words, vertices Vj and are reachable from each other. 
The strongly connected components in die trajectory assertion can be identified with a linear time 
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0(M^ + £) algorithm[891. Let G^^ represent the acyclic component graph obtained by shrinking 
each strongly connected component of G to a single vertex. The graph G^^ is an acyclic graph 
that can be processed using the acyclic version of STE. Line 4 encodes the acyclic gnq)h G^^ , 
The vertices in these graph are traversed in topological order. Line 7 performs the greatest fixed 
point computation, if the vertex v is a representative vertex for a strongly connected component. 
Otherwise, line 9 updates the net values and global Boolean functions for vertex v m the acyclic 
graph. 



STE_Generalizecl(C){ 

IdentifySCCs(G) Line 2 

Let G^^ represent the acyclic component graph 

eiu;odeGraph(G'^^) - Line 4 

fbrea<^i state vertex v in (7*^ in topological ondter ( 

if (v is representative vertex for SCC) 

GFP_Generalized(SCC) Line 7 

else 

Update Q , OKj^ , OKj^ for vertex v Line 9 

} 

quantHyPathVarlables(G^^) Line 11 

} 

GFP„Generalizeci(SCC) { 

foreach entry point into SCC { 
P = T 

Update Q , OiST^, OKj^ due to external Incoming edges into Line 16 

while Line 17 

STE_Generalized{5CC^ ) 
Q = PWQ 

} Une 21 

foreach exit point from SCC 

Update Q , OKj^ , OK^ from to Vj^ Line 23 

} 

} 



lilgure 5.16: STE algorithm for generalized tr^ectory assertions. 

TTie routine GFP_GeneralizedO computes die greatest fixed point for every entry point into a 
strongly connected component. Consider a strongly connected component SCC with an entry 
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point as shown in Hgure 5,17. Line 16 updates the net values and global Boolean functions for 
all the incoming edges from the graph . lines 17-21 recursively computes the greatest fixed 
point of the equation: + ^ = □ STE_General!zed(5CC^) . The graph SCC^ is obtained 
from breaking cycles in the strongly connected component as shown in Figure 5.18. Line 23 walks 
from the entry point to each exit point for the strongly connected component and updates the net 
values and global Boolean functions. 



sec 




Figorc 5.17; A strongly connected component. 




Figore 5.1S: Breaking cycles in the strongly connected component 

An exact fixed point computation would require encoding the graph SCC^ with new path vari- 
ables for e^h iteration in the algorithm until the fixed point was reached In that case, the number 
of path variables would no longer be solely determined by the trajeaoty assertion. Therefore, 
line 11 uses the ternary quantification operation to quantify out the path variables introduced to 
encode the graph. The same path variables can now be reused in the next iteration. 
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Consider the generalized trajectory assertion shown in Figure 5.19- The algorithm will first iden- 
tic the strongly conneaed component shown in the shaded box. Tlie strongly connected compo- 
nent will be replaced by a single vertex to give the acychc coniponent graph shown in Kgure 5.12, 
where the vertex £ is the representative vertex for ibe strongly connected congwnent The acyclic 
component graph can be encoded as shown in Figure 5.12. 




Figure 5.19: An example a g«nieralized trajectoiy assertion. 



The graph obtained after breaking the cycles in the strongly connected component is shown in 
Figure 5.20. STE will perform the greatest fixed computation for this graph. The path variable 
is introduced to encode the graph. The variable will be quantified out at the end of each iteration of 
the fixed point conq)utation and re-u&ed in the next iteration. 




Figure 5.20: Breaking cyd^ in our example. 

The ternary existential quantification at the end of each iteration implies that STE perfonns a con- 
servative approximation of the reachability set. As in lattice-based trajectory checking, the conser- 
vative ^proximation can lead to a pessimistic verification. A pessimistic verification can generate 
a false negative, Le,, a correct circuit can be reported to be incorrect. 
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5.6 Summary 

This chapter has presented Symbolic Trajectory Evalualion as a technique to verify trajectory 
assertions on the actual circuit design. The main strength of STE is that it avoids the need to com- 
pute the next-Slate function for the entire circuit. 

The previous four chapters have introduced the main components of our verification methodology. 
What remains to put this all together itito a methodology is the theory. The next chapter defines the 
theoretical foundation for our methodology for formal hardware verification using Symbolic TVa- 
jectoiy Evaluation, 



in 



PA(X 187/277 ' RCVD AT 7/18/2005 7:43:08 PM {Eastern Dayfip 



07/18/2005 17:19 FAX 408 720 9397 



BST&Z 



■1188 



Chapter 6 

Putting It AU Together 

The last few chapters have revealed various aspects of our verification methodology. This chapter 
focuses on putdng all these concepts together and developing a firm theoretical foundation for the 
formal verification of circuits using Symbolic Trajectory Evaluation. The chapter first reviews the 
concepts of the abstract specification and the implementation mapping. STE is used to verify that 
each at)$tract assertion individually holds for the circuit under some mapping. We, however, want 
to ensure that the ^itire abstract specification holds for the circuit This chapter explores the ques- 
tion of what it means for the abstract specification to hold for the circuit under some mapping. 

6.1 Abstract Specification 

Chapter 2 introduced the form of the abstract specification. The specification is defined as a set of 
abstract assertions. Each abstract assertion is of the form: A = P"* Q, where P and Q are 
abstract formulas. Abstract formulas are defined over a set of abstract elements , Let 5 be die 
set of assignments to abstract elements, 5 = {0, 1 }" , where n — |5y| - 

The following definition and property of the satisfying set has been borrowed ftom Chapter 2, 

Definition 1 (Satisfying Set); Let the satisfying set, written as SatiAF^ , for an abstract formula 
AF be the set of assignments to abstract elements that satisfy the abstract formula. 

Property of Sa&fying Set: SatiAF^ andAF2) = S<^t{,AF {S r\ SatiAF ^ . 

In the remainder of this chapter^ we will use the notadon AF as a shorthand for Sat ( AF) . We can 
now view an assertion as defining a transition on the set of abstract assignments. An assertion 
P^Q can now be viewed as defining a transidon from the set ^* = Sat(P) to the set 
& = Sat(Q) , In these terms, die meaning of an assertion is that V(/? e P) , 3(q e Q) , such 
that (p. q) is a transition in the abstract machine. 
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Definition 2 (Abstract Assertion): Let / index the set of abstract assertions. Now we have a set of 
ab&traa assertions =s P. Q.. The set of abstract assertions can also be viewed as a set of 
tuples of the form; {P^Q^^ 

Definition 3 (Abstract Spedfication): The abstract specification can be viewed to be a set of 
tuples of the form: <{p .-}, C\ , where p - e L-'^,-- 

As an example, consider a system with two abstract elements A and B, Assume that the system has 
been specified with two abstract assertions: 

• (AisO)-(AisO) 

• (BisO)^(Bis 1) . 

In the set model, these abstract assertions can be represented as 
{ <{00, 01 }, [00. 01 », ({00, 10}, {01, II))} , where the left bit is the value of state a and 
right bit is the value of state B. 

The abstract specification is the set {<{00}. {Ol}>, ({01}, {00, Ol}>, ({10}, {01, !!}>} - 
This corresponds to three mumally exclusive assertions: 

• (A is 0) and (B is 0) (A is 0) and (b is 1 ) 

• (AisO)and(Bisl)"»(AisO) 

- (Ais l)and(BisO)^(Bi$ 1) . 

6.2 Trajectory Specification 

Chapter 3 introduced the form of the Iniplejnentation mapping. A map machine for a simple 
abstract formula j is a tuple of the form: 9^ap{s) = {V,U, E, j, r, a^, T> . The labellings 
and label state vertices with node formulas. Node formulas are defined over a sec of node ek^ 
ments N^. Let be the set of assigmnents to node elements, N {0, 1 }'" , where m = . 
Let ^jf^p^ rq>reseot the set of ail simple abstract formulas. Since there are two simple abstract 
formulas associated with each abstract element, = In, 
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Chapter 4 gave an overview of the trajectory generation phase. The following definitions and prop- 
erties of the irajectory formula and trajectory assertion are borrowed firom Chapter 4. 

Definition 4 (IVajectory Formula): The trajectory formula, written as TiF(AF) , defines a con- 
trol graph with node formulas for an abstract formula AF. 

Property of iV^ectory Formula: 17 (AF^ and AF^) = TjF(AFj ) || nr(AF^) . 

Definition 5 (TVajcctory Assertion): Given an abstract assertion, A = P ^ (2, the corresponding 
trajectory assertion is defined to be rm(A) = ^(P)//IT!r(0)]^ . The trajectory assertion 
T^iA ) is a control graph with action and reaction node formulas. The most general form is a pre- 
scient trajectory assertion. 

So far, we have viewed the mapping to be applied over abstract formulas. For the purposes of this 
chapter, it is useful to consider the mapping applied over sets of abstract assigrmients. We can view 
the user-specified map machine ^ap(s) as a m^q^ping / applied ovct Sat{s) as follows: 

Definition 6 (Set-level Mapping); Define a mapping J such that V^e IF 
J{S) = Map{s) , where S = Sat{s) 

Given tiie mapping over the sinqile abstract formulas, the mapping ov^ other subsets of S can be 
derived using tlie following property: 

Property of Set-levd Mapping: Jit nf)= J(k) \\ J{f) where ^ c S and £ S. 

A pr^ndition F can be viewed to be of the form P ~ and P^ » where P^ is the conjunction 
and domain restriction of simple abstract formulas that have single-sided map machines and P^ is 
the conjunction and domain restriction of simple abstract formulas that have double-sided map 
machines^ In terms of sets of abstract assigmnents this implies that 
Jat(F) = Sat{P^) n Sat(P^) which translates to ^ = F^ n F^ in our shorthand notation- 



1. As an aside, note that an abstract fbmiula of the fomi e (P^ wdd P^) can be written as 
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Let us now consider a set of abstract assertions (P^, S •) , where - Pf n pP . We place the 
restriction that for any two assertions J and , either Fj> n = 0 or = Pj^ . It is the task 
of the user to ensure that the set of assertions obey this restriction. We shaD refer to this restriction 
as the double-sided restriction. The reason to impose this double-sided restriction on the abstract 
specification will be made apparent later on in this chapter. The intuition is that doubl&-sided map 
machines in the precondition relate abstract inputs into a set of bidirectional circuit signals. The 
reaction node formulas in these map machines define a set of allowed responses on circuit outputs. 
If the abstract input does not appear in the precondition, STE will not check the response on the 
circuit output and an incorrect circuit may be reported to be correcL 

63 Verification of an Abstract Assertion 

Chapter 5 described bow to use STE to verify trajectory assertions on a circuit modeL Chapter 5 
concentrated on describing an algorithm to verify trajectory assertions. Here we attenq>t to obtain a 
deeper understanding of what it means to verify a trajectory assertion. 

Let us first define a model for the circuit Chapters introduced a circuit excitation function, 
r\:N-> 2^, The circuit can be modeled as a set of trajectories. 

Defiiiition 7 (Set of Thr£|{ectodes)! Define an infinite trajectory x as t = TjT2T3,.., where 

C N and € T] (Xj*, j) . And let T denote the set of aU trajectories associated with a circuit, 
i 

Let us first consider the jneaning of a trajeaoiy assertion G - ^{A) . And for the moment, we 
will consider ihe n)OSt general form of the trajectory assertion, i.e., a prescient trajectory assertion. 

Definition 8 (Meaniitg of a Trajectory Assertion): A prescient trajectory assertion G divides the 

set of trajectories into 3 separate sets, i.e„ the accept, reject, and don*t care sets. The definition of 

these sets reqmres some additional machinery. A path /? in the trajectory assenion G is a path 

from source ti^ sink. The length fimction, Uit{p) , denotes the number of state vertices in the path. 

Therefore a path of length m is of the form p ~ s, vj^, ...» v^, t wh©te v. e V'. Define an upto 

function that takes in a circuit trajectory and a path and returns an integer. The function 

k 

upto^'i.p) returns the integer k such that V '^i^ Setio^iVi)) Set(G^{v^)) and either 

/= 1 
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k ^ Un{p) or Xj^^ 1 Set«5j^v^^ r\ 5tt{KS ^(v ^ ^ . Now the accept, don't care, and 
reject sets can be defined as follows: 



Acc{G, 



DC(G,T) = < 



Rej{G, T) = 



T € r, and 
3 path p in G, upto{x.p) = £en(p) 



T G r, and 

V paths p in G, uptoi'^t p) = 
k< fe/t(p). 



X € and 
V paths p in C, wptoCx, p) < C&n{p), and 
3 path p in G, a/^ttjCi; /?) = 



A trajectory is accepted If there exists a path from source to sink in the graph such that the trajec- 
tory satisfies the action and reaction node fonnulas along the path. A trajectory is a don't caie if 
there does not exist a path in the graph such that the trajectory satisfies the action node formulas 
along the path. A trajectory is rejected if it is not accepted and not a don't care, i.e, there does not 
exist a path such that the trajectory satisfies the action and reaction node formulas and there does 
exist a path such that the action node formulas are satisfied but the reaction node formulas are not 
satisfied. 

Definition 9 (Verification of an Abstract Assertion): Consider an abstract ass^ion (^,2) and 
a circuit with a set of trajectories T. For the abstract assertion to hold for tfie circuit under a map- 
ping/, the verification task has to show that Rej[J(P)//{J{Q))^,T] = 0 . 

The construction G = J{P) II is in general a prescient trajectory assertion. Unfortu- 

natelyt it seems that a verification algarithm for a prescient trajectory assertion would not only 
need to construct the set T for circuit, but also enumerate each path in the trajectory assertion. 
This wottld be prohibitively exprasive. On the other hand, if we restrict ourselves to oblivious tra- 
jectory assertionSp then we can define verification algorithms that do not have to explicitiy cotv- 
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stnici the set T and do not have to explicitly enumerate each path in the graph. This is the reason 
that in Chapter 5, we limiced ourselves to oblivious trajectory assertions. 

Some of the relevant properties for the accept, reject^ and don't care sets are given beJow. 

Property of Mirror Operation: Acc(G^, T) = Acc{G. T) , where is the iniiror of G 
obtained by reversing the roles of the action and reaction node formulas. 

Properties of Compose Operation: We can define the accept, reject, and don't care sets for the 
parallel composition operation as follows: 

• AcciGy^ II G^, D = Acc(Gp T) n AccCGj, T) 

• RejiG^ II Gj, T) = RejiG^. T) n Acc^G^, r>u 

Acc(G J , D n ReKG2. T) u 
R£j{G^.T)nRej{G2.T) 

• DC(Gi II G2. T) = DCiG^. T) u DCiG^. T) 

6.4 Verification of the Abstract Specification 

The above verification task has shown that each abstract assertion individually holds for the cir- 
cuit. We, howcven want to ensure that the entire abstract specification holds for the ciicuiL As an 
example, assume that the verification task has been used to verify that the abstraa assertions 

{AisO)^(AisO) and (BisO)^(Bis 1) hold for the drcuii under some user-4efined imple- 
mentation msq^ping. The abstract specification corresponding to these two assertions is defined as 
following thrue mutually exclusive assertions: (A is 0) and (B is 0) (A is 0) and (B is 1 ) , 

(AlsO)and(Bisl)^(AisO) and (Ais l)and(BisO)^(Bis 1) . We want to ensure that 
the three mutually exclusive assertions hold for the circuit under the mapping. We now define what 
it means for the abstract specification to hold for the circuit. 

Definition 10 (Verification of the Abstract Spedfication): Consider the scJ of abstract assertions 
<jPs - We know that the corresponding abstract specification is the set {{p O , Qj) 
where pj € WP,. For the abstract specification to hold for the circuit with a set of trajectories T 
under a inapping J , it has to be shown that Rej\j{p-} // /f r\ G/j^' tI = 0 . 
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The verification task will ensure thai each abstract assertion individually holds for the circuit. 
MatheinaticaUy speaking, that wiU ensure Vi , RejUiP^) U (7(3^))*^, TJ = 0 .The verifica- 
tion of the abstract specification will follow from the verification of the individual abstract asser- 
tions jf the following properties hold; 

• Antecedent Property: Rej{J{P^r^P^) II Ui^))^^n^Rej[J{P{) II Ui^))^ 
when nPo^^- 

• Consequent Property: Rej{J{P) lliJ{Q{))^ .T] = 0 and 

Rej[J{P)IIU{Q2))^.n = 0 implies RejiJ{P)ll (J(Q^rxQr^))^.n = 0 , 

Consider two abstract assertions, P^^ Q and {P^wAP^^Q . The antecedent property 
ensures that if the assertion Pi^Q holds for the circuit under some mapping, then the assertion 
{P^ and P^) Q ^so holds for the circuit. In other words, if the mapping of the set Pi leads to 
an element in the mapping of the set ^ , then the mapping of a subset of Pi should also lead to an 
element in the mapping of set ^ . 

Consider two abstract assertions, P ^ fij and P^Q2' The consequent property ensures that if 
both assertions P^Qi and P ^ Q2 circuit under some mapping, then the assertion 

P f 0i and Q2) also holds for the circuit In other words, if the mapping of the set P leads to 
an element in the msq?ping of both sets Qi and Q2 , then the mapping of P should also lead to an 
element in the mapping of the set n Q2 • 

The next two sections provide a proof for these properties. As will be seen, the double-sided 
restriction on the set of abstract assertions is required to prove the antecedenot property. 

6AA Antecedent Property 

Proof: Consider die set of assertions {(Pj, Q>, (Pj, ^} . We know that Pj - Pf nPf and 
^ ^ ^ 

Pj s! P^nP§, From the double-sided restriction on the set of assertions we have that either 
P\^Pz = 0 or Pf = Pf • Since we want to consider die case only when P^ n Pj * 0 , l^us 
assume that P^ = Pf = Pf . 
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Figiiie 6.1: Construcdon of graphs G and 6'% 



The trajectory asseitiod /(P, n P^) // Ui^))^ = [J(P^) II II J{Ph^ II iJi&))^ - 
We shall refer to this trajectory assertion as C. Consider an infinite trajectory x 6 RejiG. T) . 
Since x is rejected there exists some vertex v in G and an index k such that Xj^ € A and t^^^ R 
where A and /? are set of action and reaction node assignments associated with vertex v , In other 
wortls A = Jet(a^(v)) and R = Set{a^(yy) . Assume that the votex v is tlie result of com- 
position of vertices V, in JiPf) , in y(P|) , V3 in J(P^) and in [/(^)]^ as shown in 
Figure 6.1. Let A , and A2 be the set of action node assignments associated with vertex v j and 
respectively. Since 7(jPf ) and J(P|) are single-sided mappings, we know that Ae reaction node 
assignments is the set AT, Let A3 and be the action and reaction node assignments associated 
with vertex . And let A4 and /^^ be the action and reaction node assignments associated with 
vertex v^. Sit^ce v is the r&sult of composing vertices to v^, we have that 
A = AiOAjnA3nA4 and R = R^nR^, Therefore, -1^^^ A^r\A2r\A^r^A^ and 

The trajectory assertion nP{) II Ui^)f^ = ^P^) II ^(P^)^ H 1-^(2)1^ - We shall refer 
to this graph as G" . We know that there exists a vertex v" in G" that is the composition of vertices 
Vj in 7(Pf) , V3 in J(P^) and in [/(S)]^ , Th^efore, the action node assignment associ- 
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aled with v" is A" = n n A^. The reaction node assigoment associated with vertex v" is 
= R^r\R^, Therefore, we know that € A" and. e R" . This implies that 
T e RcjiG\ T) too. la other words, ajiy trajectory rejected by the graph G has to be rejected by 
the graph G" - This completes the proof. 

The safest way to impose the double-sided restriction property is for the nser to ensure thai 
abstract elements with double^sided map machines appear in each and every abstract assertion. Let 
us consider an example to shown the inqjortance of this property. 

Consider an abstract system with abstract elements A, B, and C. Assume that the abstract system 
perfonns the conjunction of the inputs, A and B, to generate the output C. Assume an implementa- 
tion of the abstract system that uses interface protocols to obtain the A and B operands as shown jn 
Figure 6-2. Tlie protocol for fetching the A and B operand is implemented with Mooie machines* 
Consider the A operand. The data is received when the rdyA signal goes high. On an active rdyA 
signal the machine transitions to state S2 and acknowledges the data. A similar case can be made 
for the B operand. However, let us assume that there is a bug in the circuit, so that the B data is 
never iicknowledged. Tn other words, the ackB signal remains at logic 0 for both states S 3 and S 4. 




Figure 6«2; An implementation for our example system. 
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Further, assume thai the us&r provides the double-sided inap machines for the A and B operands as 
shown in Figure 6.3, 



(rdyAisO) 



(rdyA is 1) and (dacA is a) 



(ackAis 0) 




^ 3^ap{A is a) 



(rdyAisO) 



(ackAisl) 



(ackAlsO) 



(rdyBisO) 



(r dyB Is I) and (olatB is b) 



(ackBisO) 




9€ap(B is b) 



(rdyBisO) 



(ackBis I) 



(ackBisO) 



figure 6^3: The imptemeutaliQn mapping for our example^ 

For the moment, let us ignore the double-sided restrictioii property. Consider that the user speci- 
fied the abstract assettSon {A is 0) ^ (C is 0) . STE can be used to show that the abstract asser- 
tion holds for the circuit under the given implementation mapping. Having shown that the more 
general abstract assertion, (A is 0) (C is 0) ♦ holds for the circuit, we would like to infer that 
the more specific abstract assertions, (Ais 0>and (S is 0) ^ (C isO) and 
(A is 0) and (B is 1) (C is 0) , will also hold for the circuiL We, however, know that this is 
not true. Hie specific abstract assertions will be rejected by STE due to the check for the ackB 
signal 

The reason for this problem is that the user ignored the double-sided restriction property. The 
abstract assertion (A is 0) ^ (C is 0) is not a valid assertion. Both A and B have double-sided 
mappings. Therefore, both A and B have to appear in each and every abstract assertion- 
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6.4.2 Consequent Property 

Proof by Contradiction; Assume that RejlJ{hfHJiQi))^>T] = 0 and 

The trajectory assertion Jih If UiQy n Q^)\^ = J{P) II !l ^C^)]^ • shall 

refer this trajectory assertion as G. There is at least one infinite trajectory % e Rej{G, T) - 
Since x is rejected there exists some vertex v in G and an index k such that "t^^ A and t^, « 
where A and jR are set of action and reaction node assignments associated with vertex v . Assume 
that the vertex v is the result of composition of vertices v j in J(P) , in lJiQ{)]^ , and in 
UiQo)}^ . Let and R-^ be the set of action and reaction node assignments associated with 
vertex , Let A2 and /?2 ^® *® action and reaction node assignments associated with vertex V2 - 
And let A^ and be the action and reaction node assignments associated with vertex V3 , Since 
V is the result of composing vertices v^, V2 and we have that A - A^ nA2'^ A3 and 
R ^ n i?2 n /ig . Therefore € A^rsAjnA^ and 1^ ^ i?j nU^^^s • 

Consid(^ the trajectory assertion J{P) // [/(Qi)]*' - We shall refer to this graph as <7' . We 
know that there exists a vertex y" in G" which is the composition of vertices in J(P) and 
in [7(2 1)]^ ■ Therefore, the action node assignment associated widi is A" = Aj nAj. The 
reaction node assignment associated with vertex v" is i?" = i?j n ■ Since RejiG\ T) = 0 y 
the trajectoiy t could belong either to the accept or don't care seL Since we know that 
z^B A J n Aj, the trajectory belongs to the accept set and e j n i?2 « 

Similiu-ly, 6001 trajectory assertion JiP)// [7(j22)l^ » we can obtain that x^s A, n A3 and 
T^.e o7^3- 
But now we have that Xj^e /?! r\R2nR^ and Tj^s RinR2 and Tj^e /2, nie3.Thisis acon- 
tradiction. So our assumption is incorrect This completes the proof by contradiction. 
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6,5 Summary 

The J^guages and tools were used to verify that each individual abstract assertion holds for the 
circuit under the implementation mapping. The theory made the claim that the entire abstract spec- 
ification holds for the circuit under the mapping- This required the user to ensure the double-sided 
restriction property on the abstract specification and implementation mapping. 
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Chapter 7 

Reasoning About Execution Sequences 

Once we have verified each individual operation on a circuit, we want to reason about infinite exe- 
cution sequences. This chapter describes some of oar preliminary work in the creation of execu- 
tion sequences. 

The concept of the main machine was introduced in Chapter 3. The chapter informally introduced 
the concept of composition to stitch main machines together to form execution sequences. An infi- 
nite execution sequence, however, required the conqK>sition of infinite copies of the main machine. 
This chapter introduces the concept of a closure construction as a means to stitch machines 
together to form all feasible execution sequences, 

7.1 Related Work 

Beatty reduced the task of verification for all possible execution sequences into a check for three 
separate propefties, Le., Obediencey Conformity and Distinction{\3i\[\S\, The Obedience property 
was the check to verify that the trajectory assertion holds for the cjrcuiL Hie Conformity property 
required that for every specification input sequence, thete should be a corresponding circuit input 
sequence. The Distinction property required that two distinct specification output sequences 
should have distinct circuit output sequences, Beatty was able to claim that the conformity check 
needs to be p^ormed only on the abstract inputs. Internal state elements do not need to be 
checked for conformity sixjce they appear on both sides of the assertion. 

So far, this thesis has dealt with the Obedi^ce property. This chapter is the first step towards rear 
soning about execution sequences. It remains to be seen if Obedience, Conformity, and Distinction 
represent the complete set of properties to verify all possible execution sequences in our extended 
frameworic 
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7.2 Main Machine 

Section 3,3.2 defined the main machine to be a control graph with a nextmaricer function. The 
main machine defines the flow of control for an arbitrary i^^ system operation. We can make this 
explicit by associating an operation index counter with the main machine. In this discussion, the 
operation index will be specified as a superscript on the set of v^ces- Therefore, a state vertex 
refers to a state vertex for the i^^ operation. The main machine can be defined as follows: 

Definition 1 (Main Machine): Define to be the main machine for the i^^ operation, where the 
snperscript i refers to the operation index counter. The main machine is of the form: 
M' = (VK UKE\ |J'>, where 

• ( V\ uK EK s\ is a control graph. 

* is the nextmarker function, p' : -^U^\ 

The main machine defines not only the flow of control for individual system operations, but also 
defines how operations can be stitched together to form execution sequences. An operation-level 
view of the system should not only define the flow of control i^^ operation, but all subsequent 
operations- An operation-level view of the pipeline can be obtained by augmenting our main 
nnachme with an incrementing edge, (p'(5^'), s^) . The incrementing edge is a directed edge from 
the time point where the next operation can start to the source of the main machine. A traversal 
through the incrementing edge increments the operation index counter by 1- Tlie operation-level 
view of main machine is Shown in Bgure 7-1 . The incrementing edges are shown as thick dashed 
edges. 




Figore 7«1: Operadion-level view of main machine. 

As an example, consider a simple processor with fetch, decode, and execute pipeline stages- 
Assume that all instructions spend a single clock cycle in each pipeline stage. The operation level 
view of the main machine for this processor is shown in Figure 7.2. The main machine can be 
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mtesTpreted as follows: Assume that the operation index counter i is currently 1, indicating thai we 
are processing the first operation. The state vertex F ' represents the fetch stage for the first opera- 
tion. At the completion of , we can advance to state vertex indicating the decode stage of 
the first operation. In addition, we can traverse the incrementing edge which increments the opera- 
tion index counter / lo 2, and advance to state vertex F^ . The state vertex represents the fetch 
stage of die second operation. Thus the decode stage of the first operadon overlaps with the fetch 
stage of the second operation. It can be seen that this representation succinctly captures the opera- 
tion-level view of the pipeline. 




Figure 7*2: Example 1* OperatioD-level view of main machine for simpk proccssox; 

73 Closure Construction 

It is possible to obtain a closed fonn AP of the main machine, which represents all possible exe- 
cution sequences. The main madiiDe can be viewed as describing the operation-level view of the 
machine, and the closed madiine M* can be viewed as describing the system-level view of the 
pipeline. 

Let us define as the machine obtained from composing k main machines 

Af*. + ^ . . M * * " ^ For the moment, we will informally define M** - Lat^ on, we will give a 
more ngorous mathematical definition. The resuJt of composing A + I main machines can be 
defined as Af * + 1* = Af ^ // Af ' + The operator // is ihe shift-and-<ompose operator described 
in Chapter 4. Consider that Af^ is associated with two cutsets, i.e., the A and B-cutsets. The A- 
cutset represents the time point where the next operation M' * * can start. The B-cotset represents 
the time poirrt wh^e the first operation Af ' ends. Figure 7.3 shows the effect of composition on the 
A and B-cutsets. The A-cutsct in machine ■** corresponds to the time point where the next 
operation can start in the main machine Af' The B^utset in machine ^* corresponds to 
the B-cutset in machine Af . 
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Figure 7.3: Composing main machines 

We will keep on composing main machines in ibis manner until the A-cutset moves beyond the B- 
cutset Since the B-cutset corresponds to the end of the first operation, this implies that the first 
operation AP has successfully completed- For serial pipelines with d pipeline stages, this should 
happen after composing n- 1 main machines. Therefore, in machine M^'^ ^* ♦ the cutset A*^ ^* 
should have moved beyond the cutset + ^* . In machine M^^^^, we can use a normalization 
operation to replace all transitions beyond the cutset ^ ^* by incrementing edges. 

The closure construction is a two st^ process: 

• Compose main machines. 

• Normalize the resultant composed machine. 

Details of the composition and normalization operation are presented io the noct two sections, 

73A Composmg Main Machines 

Let us first rigorously define the concept of a k-composed machine- 
Definition 2 (k-Composed Machine): Define = // M^"^ '//...// ilf^ + * - The -com- 
posed machine is defined to be of the fann: = iV^, U^'^.E^.S^^t^^A^.B^), 
where 

I3S 

PAffi2W«77^RCVDAT7f18/2C05 7:43:08PM [Eastern Day^^^^ 



07/18/2005 17:22 FAI 408 720 9397 



BST&Z 



@204 



• < V**. £/^, E^*, 5^*. r**> is a concrol graph. 

• is a vertex cut of the control graph. A** ^ U^* . 

• B^* is a vertex cut of the control graph, B^'^^U^l 

The vertex cut represents a cutsfiit of event vertices where the next operation, + ^ , can be 
started. The vertex cut represents a cutset of event vertices that corresponds to the end of the 
first operation M' - 

The 1 -composed machine M^* is a trivial case and represents a sequence of just a single opera- 
don. The control graph for M 1* JS defined to be the control graph for the main machine Af ' . The 
A-<;utsel is defined to be die nextmarker of the source of machine . Tlie B-cuts^ is defined to be 
the sink of machine M'.ThusM** = (V^*, £/l*,£l*,5i*. fl*,Al*,5^*>, where 

• = in . 

The Jfe -composed machine can be iteratively constructed as M*"*" '* = Af** // M' The 1-com- 
posed machine Af ^* will form the base case for this iteration. The start of machine Af'"^*" is 
shifted to the A-cutset of machine Af . The machines are augmented as shown in Figure 7.4. 




Figure 7 A: Augmenting main machines* 



Now; we can take the composition of the two augmented machines. The composition will carefully 
presCTve event vertices in Af^"^ ^* that are due to the B-cuiset in M^* or due to the event vertex 
+ + in Af^'"*"*. Assunne an augmented A: -composed machine 
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= ( v^, U^^, E^. ^^*, t^, A^, 5^*> and an augmented main machine 
jl^f + fc » (V'"" ^ t/^'•*•^£'■*■^^'*^^r''^^ (J'"^^. Both machines have been augmented with 
dummy vertices and have their source and sinks synchronized with each other. Then the A -t- 1 - 



• £^+1* is the set of edges. 

We will keep an composing these machines until the A-cutset moves beyond the B-cutseL The A- 
cutset is said to have moved beyond the B-cutset if; 1. A) J paths from any event vertex in the B-cut- 
set leads to an event vertex in die A-cutset and 2. There does not exist an instantaneous path from 
any event vertex in the B-cuiset to an event vertex in the A-cutset. In other words, the A-cutset is at 
least a state vr,rtex away and to the right of the B-cutset. Let us assume that this happens after d 
compositions for the machine ^Z^"*" as shown in Figure 7.5. For a serial pipeline this should 
imply that the system has d pipeline stages. Otherwise, the user gave an incorrect main machine. 




to 




figure 7^! The resuhant composed machine. 
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Consider our exampk of the simple processor with the fetch, decode, and execute pipeline stages 
shown earlier in Figure 12. The result of composing 4 of these main machines gives us the result- 
ant composed machine shown in Figure 7,6. Notice thai the cutset A^* has moved beyond B"** , 
and the state vertex + ^D^ **" ^F=*- ^ is separating the two cutsetS- 




Flguie 7.6; Example 1* The 4-composed machine for simple processor. 



13.2 Normalization 

The state vertices m the machine M*^"*" ^* can be divided into 3 separate subsets, ^j^^^m^ 
V^. The set refers to the set of state vertices to the left of the B-culseL Hie set refers to 
the set of state vertices between the B and A-cutsets- And the set are the set of vertices to the 
right of the A-cutset. We know that V^c V' x + ^ x ... x V^'-*"*^' ^ and 

^ ^ X V''"*"^ X ... X V Normalization consists of taking vertices in the set Vj^ and 
replacing them by incrementing edges to corresponding vertices^in the set . The shaded vertices 
in Rgure 13 and Kgure 7.6, just beyond the B-cutset, will be candidates for normalization. Con- 
sider an edge {a^, v^) where e B^^ and e V^. The state vertex is of the form 

+ 1.^ yi^2 yi-\^d^ ^ xhe vertex can be normalized to <v'. ^ * ^> - The normal- 
ized vertex should belong to the set V^. And now we can replace the edge («^, v^) by an incre- 
menting edge from to the normalized vertex. This construction gives us the closed fomn of the 
machine , 

Consider the example of the simple three-stage pipeline. The shaded vertex Ei + io^ + ^pi-t-^ 
can be rnprmalized to B^D^ ^F"^ ^ and we can introduce an incrementing edge as shown in 
Figure 7.7. Notice that this representation succinctly captures the system level view of the pipe- 
line. Also, the representation captures all possible execution sequences. 
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Figure 7.7: Ejtample 1- System-level view of the pipeline for simple processor- 

7*4 Examples 

Consider the example of a processor whicb has two pipeline stages, namely, the fetch and execute 
stage and where an instiuction might spend an arbitxaiy number of cycles in each stage. This 
example was introduced in Rguie 3.12. The operation-level view of the main machine for such a 
processor is shown in Figure 7,8. 




Figure Example 2. Oporation-ievel view of pipeline. 
The closure construction for this machine gives us the machine shown in Rguie 7,9. 




Figure 7.9: £xample 2. System-level view of pipeline. 



142 



PAGE 2071277 « RCVD AT 7/18/2005 7:43:08 PM [Eastern DayOght Time] ' SVR:USPTO-EFl(RF-»25 ' DNIS:2738300 ' CSID:408 720 9397 * DURATION (iniiKS):5408 



07/18/2005 17:23 FAX 408 720 9397 BST&Z I2I208 



7.5 Summary 

Closure construction was used to stitch main machines together to reason about execution 
sequences. This is only a partial solution or rather just the first step in the creation of execution 
sequences. Closure construction of the main machine just defines the effect of execution sequences 
on the pipeline structure. There is another aspect that requires checking whether constraints on the 
inputs and internal state elements are consistent in the creation of execution sequences. This 
fcquires some form of closure constmction on the entire set of trajectory assertions. A more 
detailed discussion is presented as future work in Chapter 9. 
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Chapter 8 

Cobra-Lite Verification 

Our loog-terra objeclive is to use our methodology to verify the Cobra-Lite processor. The Cobra- 
Lite processor is implemented as a set of interacting functional units. A step towards our long-term 
objective is lo veiify individual functional units. This chapter applies our methodology to verify 
the fixed point unit in the Cobra-Ute processor. In particular, the chapter describes the verification 
of arithmetic and logical instructions with two source register operands and one target r^si^ 
operand in the fixed point utut. 

The diapter starts with a brief overview of the Cobra-Lite processor with emphasis on the fixed 
point unit. The rest of the chapter describes our effort to verily the fixed point unit The arithmetic 
and logical instructions were specified as a set of abstract assertions. Details of the instruction 
pipeline, forwarding logic, pipeline interlocks, and interfece protocols were exposed in the imple- 
mentation mapping. We, as the users, provided the abstract assertions and the implementation 
mapping^ The trajectory generation phase look the abstract assertions and implementadon map- 
ping and generated the trajectory assertions. Finally, Symbolic 'Hajectory Evaluation was used to 
verify the trajectory assertion on a gate-level circuit design of the fixed point unit, A brief descrip- 
tion of our effort to verify the fixed point unit can be found in [23], 

8.1 The Cobra-Lite Processor 

Cobra-Lite is a fuUy functional prototype of the processor found in IBM's AS/400 Advanced 36 
Coniiputer[64][651. It is a superscalar implementation of the PowerPC architecture [63]. The Pow- 
erPC architecture is a full 64-bit archiiecture with a well-defined 32-bit subset. The architecture 
has 32 general purpose registCTS, 32 floating point registers, 3 branch registers and 2 exception sta- 
tus registers. The architecture supports 5 different instruction formats and several addressing 

1 . Kyle Ndson. at IBM Rcchcsier, is leading the efibrt to verify the Cobra-Lite processor. 
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modes. Cobra-Lite is an early version of the Cobra processor with the processor, cache, and I/O 
interface on a single chip. It is called Cobra-Lite since it is missing about 17 instructions from the 
required 64-bit PowerPC set. These instructions are primarily floating point instructions that were 
implemented in software. 

The Cobra-Lite processor has many of the complicating features found in modem processors such 
as forwarding logic, instruction pipelines, pipeline interlocks, multiple cycle instructions, multiple 
instruction issue, conditionally issued instmctions, and out-of-order execution. Cobra-Lite is 
implemented as a set of interconnected functional units. A high-level diagram of the dataflow 
between some of these functional units is shown in Hgure S,L 
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I'lgore 8.1: Higfi-level dataflow betwe^ m^or functional units and caches. 



The initial atteir^t will be to individually veriiy three of these functional units, i.e., the fixed point 
unit (FXU), load store unit (LSU), and branch processing unit (BPU). The floating point unit 
(FPU) is outside the scope of the languages and tools described in this diesis. Our Symbolic 
jectory Evaluate^' uses ordered Binary Decision Diagrams to perform the symbolic computation. 
Binary Decision Diagrams are not suited to rqjiesent floating point functions. Recently research- 
ers have explored alternate data structures to represent floating point functions[751. An attempt to 
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verify the FPU would require the incoiporation of these data structures into Symbolic Trajectory 
Evaluation. 

The im piemen tali on of the Cobra-Lite processor is described ia the VHDL language thai was syn- 
thesized down to the gate leveL A measure of complexity of the processor is the number of gates in 
individuaJ functional units. The FXTJ circuit has 22,942 multi-input gates and 1 092 Jatches- The 
LSU circuit is even more complex and has 85,487 multi-input gates and 6912 latches. 

The next few sections briefly describe the three ftinctional units, j.e., the BPU, LSU, and FXU with 
emphasis on the FXU. 

8.1.1 Branch Processing Unit 

The branch processing unit (BPU) fetches up to two instructions per cycle from the Instruction 
Cache (Icache). The BPU can pre-fetch up to four sequential instructions or two branch target 
instructions. A maximum of two instructions can be dispatched per cycle depending on the number 
of valid pr&'fetched instructions and interlock conditions set by previously dispatched instmctions. 
All instructions are pre-decoded and steered to the correct functional unit If a branch is detected in 
the instruction stream and the effective address is available, the BPU will attempt a conditional 
fetch of the target instruction. Instructions following the branch are dispatched conditionally. 
When the branch is resolved, instructions dispatched conditionally are allowed to execute if the 
branch is not taken, or are cancelled if the branch is taken. The BPU also implements a number of 
architBcted registers (e.g., condition code registers) and interfaces to the EXU, FPU, and LSU to 
allow access to these registers. 

8.1.2 Load Store Unit 

The purpose of the load store unit (LSU) is to execute the subset of the architected fixed point 
instructions that access main storage. These instructions are dispatched to the LSU by the BPU. 
The LSU decodes these instructions, performs the rwcessary effiactive address calculation, and 
interfaces with the Data Cache (Dcache) and the Storage Control Urdu 
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In the Cobra-Lite architecture all targets for loads and sources for stores are GPRs. There are 
thirty-two 64-bit GPRs in the architecture. These registers are contained in a sub-chiplet of the 
LSU. The I^U is responsible for the bookkeeping of the GPRs so that even though the processor 
is executing insuTictions simultaneously or possibly out of sequence^ the GPRs contain the archi- 
tecturally correct value should an interrupt occur. This is done by a scoreboarding scheme that 
marks GPRs as busy when an update is pending and frees them when the update is complete. 

The FXU needs to access the GPRs to perfonn arithmetic and logical operations. To provide this, 
the LSU has an interface with the FXU that allows the FXU to request GPRs for operand sources 
and store back GPRs for destinations. The LSU is responsible to check if the GPR is busy pnor to 
supplying it to the FXU and marking the destination GPR busy while the FXU is performing the 
operation. 

The LSU circuit has in excess of 80,000 multiple input gates and nearly 7000 latcbes. 

8,13 Fixed Point Unit 

The fixed point unit (FXU) is responsible for executing all fixed point instructions other than loads 
and stores. The FXU interfaces with the BPU and LSU. Instructions are received from the BPU 
with an acknowledge handshake. If the FXU is busy and cannot receive the instruction, then no 
acknowledgment will be given to the BPU- The instruction wiD stall in the dispatch stage, and the 
BPU will try to dispatch it again in the following cycle. 

The FXU processes instructions in three stages, i.e., the dispatch, decode, and execute stages. The 
instruction is received from the BPU in the dispatch stage. In the decode stage, the latched instruc- 
tion is decoded into the instruction fields. Requests are made to the LSU, where the general pur- 
pose registers (GPRs) reside. A target operand, if required, is also reserved in this stage. The 
required register source operands will come from one of two places. If the source register address 
is equivalent to the target register address of the instruction in the execute stage, then the source 
data will be forwarded to the decode stage, bypassing the register file. Otherwise, if there is no reg- 
ister match or if there is some special circumstance in which the hardware does not support regis- 
ter bypassing, a request for the data is sent to the LSU. Part of the LSU's function is to manage all 
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the interlocks involved in the allocation of register rcsouices. Instiuctions will stall in the decode 
siage undl all the source operands are available and the execute stage is available. The execute 
stage is considered available when either it does not cimcndy contain a valid instruction or the 
instruction in the execute stage is going to be completed in the current cycle. 

When the execute stage begins, all required operands are available and the current instruction is 
latched into the execute stage instruction register- Decoded fields from the decode stage are latched 
to prevent having to le-decode them. Most instructions will complete the execute stage in a single 
cycle. Multiply and divide instructions are the exceptions. Result data is provided to the LSU and 
the instruction is completed when the LSU acknowledges the store. This acknowledgment may be 
delayetl, causing the instruction to stall, if there are prwious mstructions in the instruction stream 
that still have tlie possibility of causing an interrupt. 

The FXU can execute one instruction per cycle if instructions are available, no contention occurs 
for GPR resources, and there are no delays due to interrupt possible conditions. The FXU can 
complete instructions ahead of the LSU until a resource contention condition is encoimtered. 

The FXU circuit has in excess of 20,000 multi-input gates and in excess of 1000 latches. 

The complexity resulting from both the interlock logic that enforces pipeline stalls and the nonde- 
terministic interfaces between the FXU and other functional units are common in modern proces- 
sors. These features are a significant source of errors and iriCTease the difficulty of the verification 
task. 
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8.2 Abstract Specification 

This chapter concentrates on veriiying three-register instructions in the fixed point unit. Three-reg- 
ister instructions are arithmetic and logical instmctions with two source register operands and one 
taiget register opmnd. Each thi^-register instruction is specified as an abstract assertion. As an 
example, the abstract as&eition for the three-register bitwise-OR instruction is as follows: 



WHEN ((ra !« rb) || (dataA = dataB)} (1) 

(op Is or) and (2) 

(fa is ra) and (RB is rb) and (RT Is rt) and {3) 

(Reg[ra] is dataA) and (Reg[rb] is dataB) (4) 

LEADSTO (5) 

(Re9[rt] iS dataA | dataB) (6) 



Lines 2-^ contain the precondition of the abstract ass^on. Line 2 specifies that the opcode must 
be that for the OR instruction. Line 3 uses the symbolic variables, ra, rb, and rt, to specify that 
the source operands, RA and RB, and the target operand, RT, can be any register address. Line 4 
specifies the contents of the two source registers to be the symbolic values dataA and dataB. 
Line 6 specifies that in the postcondition the content of the target register will contain the bitwjse- 
OR of the data in the two source registers. Line 1 is a global domain restriction that filters out ille- 
gal patterns. An illegal pattern would be when the two source operands refer to the same register 
address and the data contained in the two source registers is different. 

In the remainder of this chapter, we will refer to the thtee-register instruction being verified as the 
Instruction Under Test (lUT). The three-register bitwise-OR instruction will serve as a representa- 
tive lUT. 

8.3 Implementation Mapping 

Figure 8.2 shows the high-level flow of information between die BPU, LSU, and FXU for the 
instruction under test (ILJT). The FXU has three pipeUne stages, i.e., the dispatch, decode, and exe- 
cute stages. The FXU receives the instruction from the BPU in the dispatch stage. The instrucdon 
has the opcode and the three-register addresses. The FXU obtains the source operands from the 
LSU in the decode stage. The operation is performed in the execute stage and die result is stored 
back in the target register. 
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BPU 

'X{op, RA. RB. RT) is {OR. ra, irt } 
Dispatch 

Decode 

Execute 
FXU 

Flgiire 8^: High-level inTormatioii flow for instroctioD onder test 

The implementation mapping has to relate the high-level infonnation flow to a transfer of logic 
values on actual signals in the circuit The signals involved in these transactions are shown in 
Figure 83. The abstract clauses are mapped into protocols involving the interface signals between 
the FXU, BPU, and LSU. The abstract clause {op, RA, RB, RT) is {OR, ra, rb, rt} is 
mapped into a protocol on interface signals between the BPU and FXU, The abstract clauses 
(Reg[ra] is dataA) , (Reg[rbJ is dataB) , and (Reg[rt] is dat aA|dataB) are 
mapped into protocols on interface signals between the FXU and LSU A detailed description of 
each signal will be given later while describing individual map machines* 



^ Reg[ra3 is dataA 
^ Reg[rb] is dataB 
Reg[rt] is dataA I dataB 



LSU 
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Figure 83: The set of signals exposed in the implenienfation mapping. 

Our incecicion is to verify the lUT under eveiy possible sequence of leading instructions. One pos- 
sible way to rqwesent all leading instruction streams^ is to issue two completely symbolic instruc- 
tions before issuing the lUT to the FXU, The problem with tills approach is that the symbolic 
computation required for the leading instnicdons is prohibitively large. Therefore, we capture all 
possible leading instructions streams by exposing and asserting some of the internal state elwnents 
in the FXU. Note that only a limited number of internal state ebments interact with the lUX Apart 
from the interface signals, we had to expose only 8 internal state elements in the FXU. Some of the 
more important internal state elements that have to be exposed in the mapping are shown in 
Figune 8,3, The internal signals dcdHasT and dcdSelT are asserted in the dispatch stage and 
checked in the decode stage. The internal signal exBusy is asserted in the decode stage and 
checked in the execute stage. Again a detailed description of these signals will be presented later 
while describing individual map machines. 
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The next few sections describe the details of the implementation mapping for the FXU. The map- 
ping describes a cycle-)evel state vertex. The main machine and set of map machines are defined in 
terms of cycle-level state vertices. A map machine is defined for each abstract element in the 
abstract specification. In addition, map machines are also defined for some of the internal state ele- 
ment of the FXU that are exposed in order to capture the past history of the processor. 

83.1 Cycle-Level State Vertex 

The Cobra-lite processor has a two-phase latch structure. Each storage element is two latches in a 
master-slave connection. The master latches are called the LI latches and the slave latches are 
called die L2 latches. The processor uses two clock signals, i-e., the CLl and CL2 signals, to oper- 
ate these latclies. A cycle-level vertex is defined in terms of two phase-level vertices, Ll and L2, 
as shown in Figure 8.4. 



CCLlisO)and(CL2 isl) 




F^ure 8.4: CydC'level vertex for the FXU. 



8*3.2 Main Machine 

The main machine for the FXU is shown in Figure 8.5. The vertices dsp, dcd, and exe are cycle- 
level state vertices which represent the three pipeline stages in the FXU, The self loops on each 
state vertex represent that an instruction can staD in each pipe stage for a nondeterministic number 
of cycles. The successive instruction can he started ai event vCTtex ni2, thus overlapping the decode 
stage of the current instruction with the dispatch stage of Che successive instruction. 
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Nextmariter 




Figure 8^: Main machine for the FXU* 

8.3.3 Dispatch Stage Map Machines 

The abstract clause (op is OR) is mapped into a protocol on the interface signals between the 
BPU and EXTJ. The signals involved in this transaction are shown in Figure 8-3- The BPU asserts 
the signal bpVall when an instruction has to be dispatched to the FXU. The signal bpVall is 
kept asserted until the FXU acknowledges receiving the instruction by asserting the signal 
f xAckl. In addition to bpValI» the BPU also asserts the bps lot signal The BPU can dispatch 
two instractions per cycle, Tbe signal bpSlot indicates the sltrt for the dispatched instruction. 
The 32-bit bpl signal defines the opcode and operands for the mstniction. The format for three- 
register instrxictions is shown below: 



0 6 11 16 21 31 




Register Addresses 



This transaction is captured in the map machine ^ap(op is opcode) . A textual description of 
a pait of the ma]} machine is given in Figure 8.6. The map machine defines a control graph in tenns 
of cycle-level state vertices. The control graph is syncbronized with tbe dispatch stage of the main 
machine. The labels define the action and reaction node formulas assodated with the state vertices. 
Tbe node formulas are dependent upon the opcode of the instruction. 
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MAP (op IS opcode) { 

VEFTTEX S1.S2. S3: cycle; 
VERTEX el . e2. ©3, e4; EVENT; 
NEXT{ 

el:{Sl,e2}; 

e2: {S2. e3}; 
S2:{S2.e3}; 
e3: S3; 
S3: e4; 

1 

SYNCH {el: maln.ml, e4: main.m2}; 
VARIABLE sit BIT; 
CASE (opcode) { 
IS OR: 

ALABEL { 

(bpVall IS 0 at SI .LI) and (bpVaJI Is 1 at S2.L1 ) and 

(bpVall IS 1 at S3.L1) and (bpStot Is sit at 33.L1 } and 

(bpl[0:5] is "01 11 1 r at S3,L1 > and (bpl[21 :31I is XHOI 1 1 1 000* at S3.L1 ) 

} 

CLABEL { 

(txAcklisOatS1.L1> and (txAckl is0atS2.L1) and (IxAckl Is 1 aiS3.L1) 

} 

IS AND: 

} 

} 

Figure 8,6; Map machine for (op is opcode)* 



Map iracliiiiies for the register addresses, RT, RA, RB can be described in a similar manner. All 
these map machines are synchronized to the dispatch stage of the main machine. The map 
machines define the trajectory formula for each simple abstract formula in the abstract assertion. 
The tnijectory formulas for the operation and the register addresses is shown pictorially in 
Figure 8.7. The next few paragraphs discuss each of these trajectory formulas- 



The unajectory formula f^f(op is OR) is derived from the map machme 1^ap(op is opcode) , 
The control graph has three state vertices, SI, S2 and S3. The action node fonnulas associated 
with each state vertex are shown in the upper half and the reaction node formulas are shown in the 
lower lialf of the shaded box. The action node formula on state vertex 52 asserts the signal 
bpVal I. The action node formula on state vertex S3 sets the opcode and extended opcode for the 
three-rugister bitwise-OR instruction. The signal bpSlot is asserted to a symbolic variable sit 
to indicate that instruction might tmve been dispatched in either slot The BFO might have to wait 
for an indefinite number of cycles before the FXU acknowledges die mstrtictioo. The check on the 
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signal f xAckl in the reaction node fonnula on state vertex S3 ensures that the instruction is even- 
tually acknowledged. 

The trajectory formula TTCrt is rt ) sets ^propiiate fields in the bp I signal for the target reg- 
ister address. 

The decision to fetch the source operands from the register file or forward the data is made in the 
dispatch stage. Forwarding is dependent upon the previous instruction. The two instructions 
involved in the decision are the previous instruction in the decode stage and the lUT in the dis- 
patch stage. Eventually the previous instruction wDl move into the execute stage and forward the 
data to the lUT in the decode stage. The FXU requires the following conditions to forward data 
from the execute stage: 

1 - Previous, instruction should have a target register address. The internal signal dcdH&sT indi- 

cates whedier the previous instruction liad a target register. 

2 • A proper sequencing of instructions. In particular, two FXU instructions have to be issued in 

consecutive cycles by the BPU with no intervening LSU instruction. 

3 - The target register address of ±e previous instruction should match the source register address 

of the lUT. The internal signal dcdSelT stores the target register address of the previcHis 
instruction. 

The clause (PrevI is Any) is appended to the precondition to denote an arbitrary previous 
instruction. The equivalent clause appended to the postcondition is (PrevI is OR) since we 
know that die previous instruction in the postcondition is the lUT, Le. the bitwjse-OR instruction. 
The map machine for the abstract element PrevI exposes the internal signals dcdHasT and 
dcdSelT in tiie FXU. The map machine is used to derive trajectory formulas for both the precon- 
dition and postcondition. The trajectory formula 'r?"(prevl is Any) sets the internal signals to 
indicate an arbitrary previous instractioiL Tlie action node formula on state vertex SI sets the sig- 
nals dcdSelT and dcdHasX to symbolic variables prt and trg respeaively. The trajectory 
fonnula ['Er(previisOR)l^ has a reaction node formula to check the internal signals. The 
signal dcdSelT is required to be the target register address of the OR instruction, i.e., the sym- 
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bolic variable rt. The signa] dcdHasT is required to be 1 to indicate that the OR instniCtion has 
a target register address. 

The trajectory fonnulas Tfr(RAisra) and TJ'CRBisrb) sets the appropriate fields in the bp X 
signal for the A and B source register addresses- The trajectory formulas have two legs. The top 
leg, with state vertices Si and S2, represents the case where die source oper^d will be fetched 
from tlie LSU. The bottom le^, with state vertex S3, represents the case where the source operand 
will be forwarded from the execute stage. The state vertex S3 sets the source address to the sym- 
bolic variable pxt, i.e^ the target address of the previous instructiOTi. Since the FXU requires two 
instructions to be received in consecutive cycles to permit bypassing, the bottom leg does not per- 
mit any stalling in the dispatch stage. 

This section has presented a somewhat simplified view of bypassing in the FXU. The actual details 
are a bit more complicated. A few more signals are required to ensure that there are no intervening 
LSU niStnicrions between the two FXU instructions. 
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Ss 1 ) and (bpSlot is ^It) and (t)pl[0:5] is hlF) and (bpl 


[21:31] is h378) 




(fxAcklisl) 






77*{RAis ra) 



(bpl(l6;l01isrb) 



7!r(RBis rb) 



(bpl[16:101 isprt) 



F^ure $«7; Dispatch stage map macbines* 
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8.3.4 Decode Stage Map Machines 

The absiract clauses (Reg[ra] iSdataA) and (Reg[rb] is dataB) are mapped into pro- 
tocols on the interface signals between the FXU and LSU. The signals involved in this transaction 
are shown in Figure 8.3. The data operands can either be obtained from the LSU or forwarded 
from ihe execute stage. Consider the a operand data. If the data has to be obtained from the LSU, 
then tlie FXU will assert the signal f xReqA and set the signal f xSelA to the register address. 
When the data is available, the LSU wiU assert the signal IsValA and send the data on the signal 
IsDarA. If the data has to be forwarded, die execute stage will assert the signal f xValT to indi- 
cate that the signal f xDat T has the required data operand. 

The trajectory formulas for the data operands is shown in Figure 8.S. The trajectory formulas are 
synctoonized to the decode stage of the main machine. The action rnxle formulas are shown in the 
upper half of the shaded box. The reaction node formulas are shown in ihe lower half of the shaded 
box. Consider the trajectory formula for the A operand, T:F(Reg[r a] is dat aA) . The trajec- 
tory formula has two legs. The top leg, with state vertices SI and S2, represents the case where the 
A opei'and is obtained from the LSU. The reaction node formulas on state vertices Si and 32 
check that the FXU makes a request for the A operand from the symbolic address r a in the register 
file. Tlie action node formulas on state vertices SI and S2 indicate that the LSU waits for an arbi- 
trary number of cycles before indicating that a valid data has been placed on the signal Is Dat A, 
The bottom leg, with state vertices S3 and S 4, represents the case where the A operand is for- 
warded from the execute stage. The execute stage waits for an arbitrary number of cycles before 
placing the forwarded data on the signal f xDatT. The two legs converge into the state vertex S5. 
State vertex S5 represents the condition where the decode stage has obtained the A operand but 
aright still be waiting to obtain other resources such as the B operand. The trajectory formula 
(?!F(Reg[rb] is dataB) can be explained in a similar fashion. 

The lUT can move from the decode stage to execute stage if the execute stage is not busy. How- 
ever, iJ" the execute stage is busy, then the lUT will stall in the decode stage. If the execute stage is 
busy, the lUT cannot move to the execute stage until the decode stage receives the f xValT and 
IsAckT signals. The f xValT signal indicates that the execute stage has generated the result. The 
IsAckT signal indicates that LSU has accepted and stored the result in the register file. This con- 
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dition is represented in the trajectory formula 75^ (P r e v I is An y ) for the execute stage. The tra- 
jectory formula has two legs. The bottom leg, with state vertices 51, S2, and S3, represents the 
case where the execute stage is busy. A valid target is generated in slate vertex S2. The LSU sends 
the acknowledgment in state vertex $3. The top leg represents the case where the execute stage is 
not busy, i.e., did not have a valid instruction. The two legs converge into state vertex S 4. The state 
vertex S4 represents the case where the execute stage is available, but the lUT might be waiting 
for other resources such as the source operands.| 

The above discussion has ignored some of the complications arising due to interactions between 
data forwarding and the signals exBusy and f xValT. Assume that the A operand is being for- 
warded fironj tlie execute stage. This inopj jes thai we are on the bottom leg of the trajectory formula 

(rjF(Reg[ra] is dataA) . Forwarding requires a valid instruction in the execute stage. Tliis 
requires us to restrict the composition of the bottom leg of the trajectory formula 

TJ"(Reg[ra] is dataA) to the bottom leg of the trajectory formula (nF(Pi:evI is Any). 
Also, forwarding cannot occur until the execute stage has a valid data, i.e., the signal f xValT has 
been assented. This requirement can be met by synchronizing event vertex e2 in the trajectory for- 
mula T^(Reg[ra]is data.A) with event vertex e2 in the trajectory formula 
TiF(PrevI Ls Any) . However, remember thai the synchronization function is from event verti- 
ces in the map machine to event vertices in the main machine. We end up compHcatiog the main 
machine by dividing the decode stage into two legs. One leg represents the case where the source 
operand is being forwarded whereas the other leg represents the case where the source operand is 
obtained from the LSU. And the bottom legs of the map machines are synchronized to the for- 
warding leg of the main machine. 
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(exBusy is 1) 
(f xVaiT fe 1) and (IsAckT Is I) 



Figure 8«8: Decode stage map machiiic& 
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8 J.5 Execute Stage Map Machines. 

The postcondition clause (Reg[rt] is dataA|dataB) is mapped into a protocol between 
the FXU and l-SU. The signals involved in this transaction are shown in Figure 8.3. The execute 
stage indicates that the taiget data has been generated by asserting the signal f xValT. Tlie register 
address is placed on the signal f xSelT and the target data is placed on the signal f xDatT. The 
LSU indicates that the data has been stored by asserting the IsAckT signal. 

The trajectory formula for the postcondition is shown in Figure 8,9. The reaction node formulas on 
state vertices 5;l and S2 check that the FXU has generated the result of the bitwise-OR operation 
and is asking Ihe LSU to store (he result in the target address in the register file. The LSU might 
wait for an arbitrary number of cycles before storing the result The action node formula on state 
vertex 52 acknowledges the end of the transaction. 



m3 



Main 




m4 

t 



T 



(IsAckXlsO) 



<f xvalT is 1) and (f xSelT Is rt) 
(f xDatTiS dataA|dataB) 




[Oy (Reg[x:t ] is dat aA| dat aB)]^ 



(IsAckTiSl) 



(f xvalT is 1 J and (f xSelx is rt) 
(fxDatTisdataA|dataB) 



Figure BS: Execate Stage Map Machines. 



For ease of exposition, the above description of the implementation mapping has been simplified 
to some extent Some of the more subtle signals thai deal with forwarding, multi-cycle instructions 
and effects of stalling in the LSU have been ignored in this description. The complete implementa- 
tion mapping for three-register instructions has 24 m^ machines. The textual description consists 
of approximately 600 lines of map code. 
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8.4 Trajectory Generation 

The tnijectoiy generation phase took the abstract ass^ons and the implementation niapping and 
generated the trajectory assertions. The trajectory assertion, shown in Figure 8.10, corresponds to 
all possible cases that can arise due to interactions between the map machines. The trajectory 
assertion has 224 cycle-levc) vertices and 34 loops. Tlie connesponding acyclic component graph 
has 28,602 paths firom source to sink. Each path represents a tmique ordering of events for a partic- 
ular set of inputs ax>d constraints on interna] state elements. 




dcd_T;o_exe cutset 



Figure &10: The trajectory assertion for three-ivgister instrucdons* 

Some intuitive sense can be made out of the graph. Notice the horizontal cutsets in the graph. The 
dsp_t o_dcd cutset corresponds to the event vertex m2 in the main machine. The dcci_t o_exe 
cutset corresponds to the event vertex in3 in the main machine. The cutsets divjde the trajectory 
assertion into the dispatch, decode, and execute stages. The decode stage of the gr^h is signifi- 
cantly mote complex than the dispaxch and execute stages. The reason is that the bulk of the con- 
trol logic in the circuit resides in ihe decode pipeline stage. The decode pipeline stage is 

l£3 
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responsible for obtaining and reserving multiple nesources. The various possible oiderings in 
which these resources can be obtained and reserved accounts for the complexity of the decode 
stage. The dispatch and execute stages, on the other hand, require a singJe acknowledgment in 
order to complete the pipeline stage. 

A high-Ieve] view of the trajectory assertion is shown in Figure 8-11, The figure shows the details 
of the dispatch and execute stages. The decode stage is represented by the shaded block- 



d5p_t:o_dcd cutset 



Dispatch 



Decode 



dcd_tq>_exe cutset 




Execute 



sink 



Figure High-level view of the trajectory assertion for three-t«gl^r in^trnctions. 

The dispatch stage can be divided into 4 vertical slices. Slice 1 is the rightmost slice from the 
source to event vertex ddl. Slice 2 is from the source to event vertex dd2. SUce 3 is the one from 
die source to event vertex dd3. And slice 4 is the leftmost slice that has all paths from the source 
to event vertex dd4. Slices 1, 2, and 3 are simple slices with only a single state vertex. These sim- 
ple slices represent the case where at least one of the source operands are going to be forwarded. 
The FXU requires two instructions to be received in consecutive cycles for forwarding to occur. 
The state vertices Dl, D2. and D3 represent the case where the FXU received and acknowledged 
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the instruction in a single cycle. Slice 4 represents the case where both operands are being fetched 
from the LSU. The state vertices D4, D5 and D6 capture the protocol between the FXU and BPU- 
The FKU receives the instruction in state vertex D5. The FXU can wait for an arbitrary number of 
cycles before acknowledging the instruction in state vertex D 6. 

The 4 slices in the dispatch stage define 4 entry points into the decode stage. Let Group 1 refer to 
the set of paths in the graph between event vertex ddl and the sink. Similarly, let Group 2, 
Group 3, and Group 4 refer to the set of paths in the graph from event vertices dd2, dd3, and dd4 
to the sink- Group 1 corresponds to the case where the A source operand is being forwarded while 
the B source operand is fetched from the LSU. Group 2 corresponds to the case wh^ the B source 
operand is being forwarded while the A source operand is fetched from the LSU. Group 3 corre- 
sponds to the case where both source operands are forwarded. And Group 4 corresponds to the 
case where both operands are fetched from the LSU. Group 4 is the most coniplex of these groups. 
This is because all the resources that are needed in the decode stage are completely independent 
The paths have to capture all possible anival orders and timings for each and every resource. 
Group 3 is the simplest of these groups. In this group, the arrival of the A and B source oper^ds 
coincides with the signal f xValT generated by the execute stage. 

The execute stage has two state vertices El and E2. The result of the bitwise-OR op^ation is 
available in these state vertices. The FXU has to wait until the LSU acknowledges the target in 
state vertex E2. 

8.5 Symbolic Trajectory Evaluation 

The trajectory assertion in Figure 8. 10 is very complex and has in excess of 28000 paths in the cor- 
responding acyclic coinponent graph. It would be computationally infeasible to eniuu^te all the 
paths and use STE separately on each path. Instead, STE encoded the graph using 456 path vari- 
ables- STE was used to verify the entire trajectory assertion in a single verificadon run. The loops 
in the trajectory assertion were dealt by performing a greatest fixed point computation. The verifi- 
cation of the three-register bitwise-OR instruction took nearly 50 hours of CPU time and 185 
MBytes of memory on an IBM RS/600 43P Model 140. 
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This may seem to be a considerable amount of time and memory. However, note that the bitwise- 
OR operation was verified under all possible bypass, interlock, and pipeline conditions and under 
all possible timings for interface with the BPU and LSU. Both the data path and control were veri- 
fied using BDDs. The CPU time appears to be more reasonable when we consider the enomnous 
number of patlis that are being verified. On an average, STE is able to verify a path in 6-7 seconds. 
An additional point is that verification of the complete trajectory assertion would most likely be 
run at the end as a regression test During the development and debugging phase, STE can be mn 
interactively to debug parts of the design by focussing the verification on problematic paths- 

Our Symbolic Trajectory Evaluator is a fir^t generation tool that was developed more from the 
point of view of completeness rather than efficiency. Several techniques could be used to improve 
the efficiency and eflfeciiveness of STE: 1. It seems possible to develop a levelized version of STE 
that would considerable reduce the number of next-state computations. 2. Our version of STE uses 
a simple-minded user-defined variable ord^ng. Advanced variable ordering heuristics and 
dynamic variable reordering could be used to reduce the complexity of the symbolic computations. 
3. Various forms symmetry and abstraction transformations could be used to simplify the formal 
verification task. Details of all these techniques are discussed as future work in Chapter 9. 

As an aside, it is not necessary to have a one-to-one relationship between instiucdons and asser- 
tions. A single assertion could be used to specify a class of instructions with the same inscruction 
format This would significantly reduce the number of assertions to be verified with a slight 
increase in the CPU time. 
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8.6 Summary 

This chapter applied our methodology to verify arithmetic and logicaj instructions in the fixed 
point unit of the Cobra-Lite processor. The specification was kept abstract at the )evd of the 
instruction set architecture. The mapping provided the complex implementation specific details for 
the FXU- STE was used to verify that the FXU circuit coirecdy fulfilled the abstract specification 
of the processor In some sense, the mapping merely s&rved as hints to guide the verification task. 

At first glance, the implementation mapping might seem to be too complex. However, note the fact 
that most of this complexity is in defining the environment around the FXU. The reality is that 
modem processors are designed as a set of reactive subsystems with complex interfaces and proto- 
cols. Therefore, any technique for formal verification of subsystems would have to deal with the 
same level of complexity. 

A large pan of the complexity in the trajectory assertion is due to pipeline stalls. The trajectory 
assertion represents all possible permutations in which various different resources can be obtained 
to resolve pipeline stalls. Our approach seems to be the first one that can truly deal with the com- 
plexity of pipeline interlocks. 
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Chapter 9 

Conclusions and Future Work 

9.1 Conclusions 

This thesis has presented a methodology for formal hardware verification using Symbolic Trajec- 
tory Evaluatioa. The methodology is targeted towards systems that have a simple deiermiiiistic 
high-level specification but have implementations that exhibit highly nondeterministic b^aviors. 
There are three main aspects of our methodology: 1- Specification Languages i Tools 3. Theory. 

The specification is divided into two components, i.e., the abstract specification and the implemen- 
tation mapping. The abstract specification defines the high-level behavior of the system, which is 
specified as a set of abstract assertions in a Hardware Specification L^guage. Each abstract asser- 
tion defines the effect of an operation on the user-visible state. Implementation specific details 
such as the system clocking, pipeline structure^ and incerfiace protocols are captured in the imple- 
mentation mapping. The implementation mapping provides a temporal and spatial mapping for 
abstract elements in the high-level specification. The mapping is defined in terms of control 
graphs, which are state diagrams with the capability of synchronization at specific time points. 

The abstract specification and the implementation mapping are provided by the user. Once the 
descriptions have been given, the tools take over, i,e„ the trajectory generator and the Symbolic 
Trajectory Evaluator. The trajectory g^erator takes in the abstract specification and implementa- 
tion and generates the trajectory specification, which consists of a set of trajectory assertions. Each 
abstract assertion gets mapped into a trajectory assertion. The trajectory assertion captures all pos- 
sible nondeterministic interactions that can arise in the implementation. The Symbolic Trajectoiy 
Evaluator is used to verify each individual trajectory assertion on the acmal circuit design- Sym- 
bolic Trajectory Evaluation (STE) can be considered to be a hybrid approach, which combines 
symbolic simulation with, some of the capabilities of model checking. The main advantage of STE 
is that it avoids the need to build the next-state fiinction for the entire circuiL 
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Once the tools have verified the trajectory assertions, it is the task of the theory to take over. The 
tools have verified that each individual abstract assertiot holds for the circuit under the implemen- 
tation mapping. The theory can make the claim that the eotjic abstract specification holds for the 
circuit under ihe implementation mapping. The user, however, has to ensure the double-sided 
restriction property on the abstract specification and iniplementation mapping. 

Once individual operations have been verified, the methodology must be able to stitch operatiorLs 
together to reason about infinite execution sequences. As the first step in this direction, a closure 
construction of the main machine is used to define the effect of execution sequences on the pipe- 
line structure. 

This methodology has been used to verify parts of the Cobra-Lite processor. The Cobra-lite pro- 
cesser is designed as a set of intercormected functional units. This thesis has concentrated on veri- 
fying one of these functional units, i.e,, the fixed point uiut (FXU), against the instruction set 
architecture of the processor. The abstract specification defines the instruction set architecture of 
the processor. The implementation mapping defines the enviroimient around the FXU. The envi- 
roiunent defines the set of protocols that is used to interface the FXU with the rest of the processor. 
In addition, the implementation moping describes features such as systsem clocking, forwarding 
logic, instruction pipehoes, and pipeline interlocks in the FXU, The thesis has presented results on 
our attempt to verify arithmetic and logical instructions in the FXU. Our approach seems to be the 
first one that can truly deal with the complexity of pipeline interlocks in modem processors. 

The long-term objective is to verify the entfce system, Le., the Cobra-Lite processor. Hie cunnent 
set of methodology and toob, however, cannot deal witii the level of complexity of an entire pro- 
cessor. T[ie initial focus is to verify each individual functional unit separately and then reason 
about the interactions among the functional units. Our work on the FXU indicates that this is a 
proroising approach for formal verification of processors. 
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9.2 Future Work 

Suggestions for future work can be divided in to the following ciltegories: 1. Languages 2* Tools 
3- Theory 4* Application 5. Miscellaneous. 

9^.1 Lai^uages 

Future work in the languages area concentrates on the implementation mapping. Woit in imple- 
mentation mapping can be classified into the following categories: 1- Extensions to the mapping to 
support complex processor feamres. 2. Enable hierarchical verification. 3, Explore alternative 
vocations for describing the mapping. 

Extensions: The current form of the implementation ms^^ping has been used to describe features 
such as forwarding logic, pipeline interlocks, multiple cycle instnictions, and multiple instruction 
issue in the FXU. The language, however, may require extensions to describe other features such 
as branrfi prediction, speculative execution, out-of-order execution, and register renaming. 

The mapping has several forms to Jimit the scope of the cross-product construction. The main 
machine uses a ncximaiker fimction to ensure that two instructions do not simultaneously occupy 
the same pipeline stage. The synchronization function synchronizes event vertices in the map 
machine to event vertices in the main machine* Map machines use the invalidate fiinction to reduce 
nondeterminism in the trajectory assertion. It would be desirable to collapse all these forms into 
one single unified fomtL^ 

Hierarchical verification: A large class of processors is designed as interconnected reactive 
subsystems. The subsystems have complex interfaces and use nondeterministic protocols to inter- 
act with each other. A clean and intuitive description of these interfaces requires a series of imple- 
mentation mappings. Each level in the mapping serves to make the assertion more concrete. An 
abstract element at the highest level could be mapped into a complex protocol defined on several 
interface signals at the lowest level. The mapping language would have to be extended to describe 
such hierarchical mapping levels. This would form the basis for hierarchical verification, where a 
verification could be performed at each level of the mapping. 
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Alternative notations: One of the concerns in this woik is that the implementation mapping can 
become very complex. An area of focus for future work would be to simplify or automate the gen- 
eration of the mapping information as much as possible. Another possibility is to explore notations 
such as armotated timing diagrams for expressing the mapping. Formalisms on Umjng diagtams 
have been studied earljer[85][86]. Some of the concepts might be applicable to this problem. 

9-2.2 Ibols 

Future work in the tools area can be classified broadly into two categories: 1. Extensions for adap- 
tive verification. 2. Improving the efficiency and effectiveness of STE. Attempts at improving the 
efficiency and effectiveness of STE could be classified into: 2a, A mote efficient Jevelized version 
of STE. 2b. Efficient m^nory modeling techniques. 2c. Use of symmetry and abstraction 
2d. Issues of BUD variable ordering. 

Adaptive verificatioii: Section 5.3.2 classified set-based trajectory assertions into three catego- 
ries in increasing order of expressiveness and complexity: 1) Oblivious 2) Adaptive and 3) Pre- 
scient. Consider a vertex v in the trajectory assertion. Now pick any two v^tices v^- and Vj such 
that (v, v.) e E and (v, Vy)e E . An oblivious tcajectoiy assertion was defined to have the 
restriction that Set{o^(y-)) r\ Set{c^(Vj)) — & . An adaptive trajectory assertion was defined 
to have the restriction that either 5fit(o^(vp) n Jet(a^(vj)) = 0 or 
Set{<s^{v^))c'\Sei{<5^ivj)) - 0 , The most general form without any such restrictions was 
called a prescient irajeciory assertion. In Chapter 5, we restricted ourselves to oblivious trajectory 
assertions. It seems possible to extend set-based trajectory checking to adaptive trajectory asser- 
tions. This would require introducing the concq>t of universal and existential edges. As an exam- 
ple consider vertices v, v, and in an adaptive crajcctory assertion such that (v, Vj) e E and 
(v, Vj) e £ . I^ A, and be the set of action and reaction node assignments associated with 
vCTtexVj,i.e. A| = Jtft(o^(vj)> and = J*t(a^(v^)) - Similarly, let and be the set 
of action and reaction node assignments associated with vertex . Since this is an adaptive trajec- 
tory assertion, we know that rather A^ n Aj = 0 or n = 0 . If A^ n Aj = 0 , keep the 
graph as is. However, if i?^^ n/?2 = ® • modify the graph as show in Figure 9.1. The edges 
(«^^v^) and v^) represent a set of existential edges, i.e., either of die edges is acceptable. 
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The three-way branch in the modified graph can be interpreted as follows: L If the next stimulus 
belongs to the s&tA^niA^, then the next circuit response can belong to the set or the set R2 . 
2. If the next stimulus belongs to the set A j n , then the next circuit response has to belong to 
the set 1 . 3* If the next stimulus belongs to tiie set A j n A 2 , then the next circuit response has to 
belong to tiie set R2 . Now the next stimulus and next circuit response together will define a unique 
vertex in the tr^ectory assertion. 





Figure 9.1: Graph modHlcatioD when /tj n = 0 - 



It is possible to generalize the above modification for an arbitrary number of vertices and write a 
set-based trajectory ciieckiog algorithm. The problem is that there does ncA seem to be a corre- 
sponding lattice-based trajectory checking algorithm. The reason is that the complement operator 
on sets does not have a corresponding operator in the lattice-based fomiulattoo. 

Levelized STE: Section 5^.3 introduced the acyclic version of the STE algorithm. The algo- 
rithm computes the next state and updates the net values and Boolean functions for each state ver- 
tex in the trajectory assertion. Consider an acyclic trajectory assertion with n state vertices. The 
ajgoritlun requires n next-state computations and n updates. It is possible to reduce the numba- of 
next-state computations by traversing the trajectory graph in a levelized order. A levelized version 
of the acyclic STE algorithm is shown in Figure 9.2. The function Cen(w) represents the length of 
the longest path from the source to the vertex w. The levelized* algorithm performs only 
Cen{t) - 1 next-State computations, where f is the sink of the trajectory assertion. 
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STE_Acyclic(G){ 

for(/ = 1 to Unity] ){ 

foreach state vertex V so that Cen(v) = i { 
Q = ^at/t(v) ? y U Latio^iv)) : Q 
OK^ ^ OK^ ■ l i^^AOT) + [y ^ ^at(a^(v))]] 
OK^ = OK^ . iTatHv) + le D Xat(a/v))]] 

} 

} 

} 

Figure 9^: A levelized acyclic STE algorithm. 

The pfoblem is that it is not apparent how to extend this levelized zilgwithin for generalized trajec- 
tory assertions. 

Efficient memory modeling: As described in Section 1.4.6, Buich and Dill have used uninter- 
preted functions to compiHre a pipelined processor with a nonpipelined version of the processor. 
The USB of uninterpreted functions aJlows Buich and Dill to specify tte initial state of the entire 
oiemoiy by a single variable. It is possible to perform Burch and Dill style verificadon with HDDs. 
The problem is that the number of BDD variables required to specify the initial state of the mem- 
ory would be prohibitively large. A variable would be required for each bit in the memory, so that 
the number of variables would be proportional to the size of the memory. It is, however, possible to 
replace the memory in the circuit by a behavioral model where the number of BDD variables 
would be proportional to the number of accesses to the memory[l IJ. The same technique can be 
incorporated into STE, enabling tiie verification of circuits with large embedded memories. 

Symmetry and Abstraction: Verification of actual circuit designs can be expensive both in 
terms of CPU time and memory usage. It would be useful to use some form of syrrunetry or 
abstraction to reduce the con^)lexity of the verification task. Researchers have used both structural 
and data symmetries to verify large static RAM circuits with Symbolic Trajectory Evaluation[24]. 
As an example, similar techniques could be used to reduce die verification to a single bit for bit- 
wise operations on words. 
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BDD variable ordering: Currently our tools use a simple minded user-defined variable order- 
ing. Future work would involve exploring various automated techniques such as dynamic variable 
reordering[71]. Sifting has emerged as one of the most successful algorithms for dynamic variable 
ordering. RecenUy researchers have looked at an extension of sifting called group sifting[74]. 
Group sifting groups variables based on their affinity to their neighbors and then sifts groups of 
variables simultaneously. Symbolic Trajectory Evaluation would probably benefit most from some 
form of group sifting. The trajectory generation phase could provide helpftil hints on how to group 
variables. 

9*2.3 Theory 

Future work in dieoiy can be classified into the ftiUowing categories: 1, Exploring the spectrum 
between model checking and STE. 2. Relation between trajectory assertion and temporal logic. 
3. Completeness aspect of our methodology. 

Model checking and Symbolic Trajectory Evaluation: Chapter 5 has presented a range of 
verification algorithms from set-based trajectory checking to lattice-based Symbolic Trajectory 
Evaluation. The set-based trajectory checking algorithm has the flavor of some model checking 
algorithms. One area of future work is to adopt and incorporate more model checking style algo- 
rithms so as to enable verification of a wider range of temporal behavior. Model checking style 
algorithms would enable verification of parts of the processor that operate as concuirent finite^ 
state machines corrmmrricating via synchronous protocols. In fact one can envision an entire spec- 
trum of algorithms and representation. At one end of the spectrum is the fast but sometimes overiy 
pessimistic lattice-based representation and algorithms that can be used to verify a limited set of 
temporal behavior* At die other end is a more communication style paradigm which is more pre- 
cise and can be used to model a wider range of temporal behavior but is compotarionally expen- 
sive. 

Trajectory assertions and temporal logic: It would be interesting to compare the expressive- 
ness ol ouT trajectory assertions widi various forms of temporal logic. Linear-time temporal logic 
(LTTL) assumes implicit universal quantification over all paths[68]. Branching-time temporal 
logic (BTTL) such as CTL allows explicit existential and universal quantification over paths(30]. 
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Our oblivious irajectoiy assertions assume universal quantification over aU paths. Oblivious trajec- 
tory assertions seem to be related in some form to LTTL, Alur and others have recently introduced 
an altemating-tinie temporal logic (AITL)[69]. ATTL offers explicit existential and universal 
quantification over selected paths. These selected paths are viewed as possible outcomes of a two- 
player game in which the circuit and environment are the two players and they alternate moves. 
Our adaptive trajectory assertions have a similar sort of flavor. The universally quantified edges 
represent moves made by the environment The existentially quantified edges represent moves 
made by the circuit. The difference, however, is that in our trajectory assertions the circuit and the 
enviromnent dfjn'thave to strictly altemaie moves. 

Completenes-s: Beatty reduced the task of verification for aU possible execution sequences into a 
check for three separate properties, i.e.. Obedience, Conformity^ and £>wft>zcn'on[13][15]. The Obe- 
dience property is the check to verify that the trajecloty assertion holds for the circuit. The Confor- 
mity property requires that for every specification input sequence, there should be a conesponding 
circuit input sequence. The Distinction property requires that two distinct specification output 
sequences should have distinct circuit output sequences. Note the fact that Conformity and Dis- 
tinction are properties of the abstract specification and the implementation mapping. They do not 
require the circuit This thesis has mainly dealt with the Obedience property. Chapter 7 used clo- 
sure construction on the main machine to create infinite execution sequences. This, however, is 
inconq)lete. We need to perform some sort of closure construction on the set of trajectory asser- 
tions to ensure that the inputs and internal state elements ai© consistent or in other words conform 
with each other. Beatty was able to claim that the conformity check needs to be performed only on 
the abstract inputs. Ihtemal state elements do not need to be checked for conformity since they 
appear on both sides of the assertion. It remains to be seen if Obedience, Conformity, and Distmc- 
tion define the complete set of properties to verify all possible execudon sequences in our extended 
framework. 
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9 J. A Cobra-Lite Verification 

Future work in Cobra-Lite verification falls into the following categories: 1. Verification of indi- 
vidual functional units. 2. Reason about interactions between functional units. 3. Methods to 
reduce complexity of verification. 4. Incorporation of new data structures in STE. 

Individual functional units; Current work has concentrated on verifying the fixed point unit 
(FXU) in the Cobra-Lite processor The next step is to use our methodology to verify the load store 
unit dSU) and the branch processing unit (BPXJ), The LSU and BPU represent more complex 
fiinctional units with a greater number of gates. The implemeniation mapping might have to be 
extended to describe the increasing levels of nondeterministic behavior in these fiinctional units. 

Interactions between functional units: Once the individual fimcdonal units have been veri- 
fied, we need to reason about the interaction between the functional units. Consider the interaction 
between the FXU and LSU, The verification of the FXU required map machines that defined the 
interfece protocols between the FXU and LSU. The verification of the LSU will use the ndrror 
image of these map machines to describe the interface between Ihe LSU and FXU. It remains to be 
seen how much work is lequiied to reason about the interactions. Some model checking style algo- 
rithms might have to be incorporated into STE to reason about the interactions between the func- 
tional imits. 

Complexity of verification: An important area of fiiture woric would be to study various tech- 
niques to reduce the complexity of verification using STE. Some of the feasible techniques are as 
follows: 1. An efficient levelized version of STE. 2. Use of efficient memory models. 3. Use of 
symmetry and abstraction. 4. Better and automated variable ordering heuristics, i Automatic 
breaking of complex assertions into multiple simpler ones. 

New data structures: Binary Decision Diagrams are sometimes unsuitable to eflftciently repre- 
sent the data path. Recently researchers have come up with alternative rcfH^sentations such as 
Binary Moment Ihagrams (BMDs)[72] and Hybrid Decision Diagrams (HDDs)[73] that effi- 
ciently represent word-level functions. One way to deal with the complexity of the data path would 
be to incorporate these data structures into Symbolic Trajectory Evaluation. 
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9,2,5 Miscellaneous 

This thesis has concentrated on usmg the abstract specification and implementation mapping for 
formal verification. These descripcions could also be used to peifonn smart or directed simulation. 
The trajectory assercioti captures all possible nondeterministic cases that can arise in the circuit. 
The trajectory JisseitioD could be used to intelligently pick a set of simulation patterns to exercise a 
larger part of ±c circuit, and provide some sort of a coverage metric to quantify what percentage 
of all possible nondetermimstic cases had been covered by the simulation patterns. 
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Appendix A 

Hardware Specification Language 

NAME 

HSL - format of the Hardware Specification LanguageJ 

The Hardware Specification Language is used to describe the high-level behavior of a system. 
The Hardware Speciiicadon Language can be used to describe several interacting finite-state 
machines. Each finite-state machine is associated with abstract elements. Apart from these, the 
language allows the user to d^ne global state elements that are visible to all machines. Eadi 
finite-state machine is defined as a set of assertions- The assertion defines a set of pre and post 
conditions that operate on state elements. 

Multiple interacting finite-state machines are assumed to operate synchronously, Le. machines 
make transitions in lock-step fashion, A fntuie possible extension is to allow the user to define 
the concurrency model for multiple interacting machines, 

DESCRIPTION 

Reserved keywords for the Hardware Specification Language are given below. 
AND AKKAY BIT DEFINE 

ENDMACHINE IS LEADSTO MACHINE 

OF RANGE STATE TO 

TYPE VARIABLE WHEN 

Tbe lower case versions of these keywords are also reserved and can be used interchangeably, 

LEXICAL CONVENTIONS 

Vertical bar I indicates choice, Question Mark ? follows optional items. Star * follows 
items that can be rq>eated 0 or more times, Plus + follows items that can be repeated 1 or 
more times, and parentheses < > indicate grouping. 

WMteSpace <SpaceChar>^- 

SpaceChar ::= blank I tab I newllne I carriage return 

Comment ::= OneLineConvnent I BlockComment 

OnelAneComment 

U any text upto newline 
BlockComment 

/* any text string that doesn't contain */ 
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Idem 

Any sequence of letters, digits, dollar sign and anderscore symbols, except keywords. 
The first chatacter has to be a letter or underscore symbol. Idents ar© case sensitive. 

IdentUst ::- Ident <*,' Ideiit>* 

A list of identifiers separated by commas. 
Integer 

An integer. 

Number 

Any non-negative integer. 

Value ::- BinaryValue I OctalValue I HexValue 

Values are enclosed within double quotes. A prefix chatacter can be used to specify a 
binary (B), octal (O) or hexadecimal (X) value, as sliown below. If a prefix character is 
not specified, then the value is assumed to be a binary, vahie. 

BinaryValue ::=B?«<Oll>+** 

In this notation, single bit values can be represented as B"0" or B"l". HSL p^nits 
'0* or as alternative notations for bit values. 

OctatValue ::= O"<0-7>+-" 

Hex^lue X"<:0-9IA-F>+" 

ORGANIZATION 

The Hardware Specification Language contains exactly one Program, as described by the 
following infoima] BNF. Ibrminal symbols are rendered in boldface and enclosed in sin- 
gle quotes. White space may be included between any items. 

Program ::= <TypeDeJn>* <StateDecl>* <Mac/une>* 

HSL supports several interacting finite-staie machines. Each finite-state machine has 
its own type definition and state declaration section. However, if the user requires cer- 
tain global type definitions and state declarations to be visible to all noachines, then 
they have to be defined before any machine descriptioDS. 

TYPE DEflNTIIONS 

TypeDefri ::= "TYPE* Idem 'IS' Types 

Type definitions give names to types. This makes it convenient to declare state and 
local variables by referring to type names- 

T^pes 

"Brr 

11= 'RANGE' Number TO* Ntdtnber 
11= X IdeniUst y 
Ident 

11= *ARRAY' Number 'TO' Number J 'OF' Types 

Bsisjc types include bit, subranges of fixed non-negative integCTS, and enumerations. 
T^pes can also be identifieis conesponding to type definitions and fixed si^ed arrays 
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of tliese types. In arrays the first number refers to the most significant bit and the sec- 
ond number to the least significant bit. The ZLSB (zero is least significant bit) nota- 
tion requires the first number to be greater than the second. The ZMSB (zero is most 
significant bit) notation requires the first number to be less than the second. Either 
notation can be used, Howcvct the same notation has to be used in all array declara- 
tions. The single bit type, integer range type, and single dimensional array of bit are 
collectively refOTed to as bitvector types. Enumerations and anay of enumerations are 
referred to as enumerated types. Array of ranges and multidimensional arrays of bit 
are referred to as multidimensional types- 

STATE DECLARATIONS 

StateDecl ::= *STATE' JdentUst Types 

The sute eleH^nts define the state space of the machine. The state elements can be 
classified into 3 categories based on their types, namely enumerated, bitvector and 
multidimensional states. Enumerated states are state elements of enumerated type. 
Bitvector states are state elements of bitvector type. The rest of the state clen)ent$ are 
multidimensional states. 

MACHINE DESCRIPTIONS 

MachiTie 

MACHINE' /^rt/-;' 

<7yp62)is/n>* 

<StateDecl>* 

<AssertBloclo* 
ENDMACHINE' 

Every machine has a unique name. Each machine can be associated with a set of type 
definitions and state element declarations that are visible only to this machine. The 
machine is defined as a set of assertions that operate on state elements. 

AssertBlock ::= 
Idem 

<A55€rtion> 

r 

The assertion block has to be associated with a name. The name is used to identify the 
assertion in the implementation mapping and ordering descriptions. Assertions can be 
associated with a set of local variables. Note that the variables are local to the block 
and are not visible outside the assertion block. 

LocalDecl ::= 'VARIABLE' JdentUst Types 

Local variables can be classified into 3 categories based on their types, namely enu- 
merated and bitvector variables. Enumerated variables are vaiiables of enumerated 
type. Bitvector variables are variables of bitvector type. The rest of the local variables 
ate noiultidimensional variables. 
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Assertion 

Clause <'AND' Clause\IR>^ 

XEADSTO^ 
Clause <'AND' Ciaw5e>* 

11= 

'WHEN' XBoolExpry 

Clause *AND' Clause>* 
LEADSTO' 

Clause ^AND* CUuise>* 
The assertion defines a set of cransitions in a finite-state moachine. Each assertion is a 
pre and post-condition pair. The semantics of an assertion is that if the precondition 
holds at the cuirent tirae> then after some passage of time the postcondition has co 
hold. However if the pre^xindition does not hold at the current tirne^ then the assertion 
phices no restriction on the set of transitions. An assertion can be qualified with a 
Boolean expression. The WHEN qualifier defines a set of transitions only when the 
Boolean expression is true. The assertion places no restrictions on the set of transi- 
tions if Boolean expression is false. The qualifier has to be a Boolean expression on 
local variables. 

Clause 

State 'JS'ExprJ 
11= 'C ^WHEN' XBoolExpry Clause 
State ::= Idera<TEpqfr'y>* 

Each clause in the assertion defines a simple assignment or a conditional assignment 
to state dements. Hie right hand side expression is an expression over Jocal variables. 
Tlie Boolean expression in the conditional assignment is an expression over local vari- 
ables. Enumerated states have to be assigned enumerations. Enumerated stales corre- 
sponding to anay of enumerations have to be indexed and assigned enumerations. 
Bitvector states can be assigned bitvector expressions. Bitvector states can be indexed 
and assigned bitvector expressions. Multidimensional states can be assigned multidi- 
mensional expressions. Multidimensional states can be also be indexed and assigned 
appropriate multidimensional or bitvector expressions. Indices have to be bitvector 
expressions. 

EXPRESSIONS 

Expr 

Integer 
\\^^ Value 

\\=Id0nt<TIndex'Y>* 

11= Expr 

\\=Ejq?r*&' Expr 

llrificprTExpr 

\\=Expr'^' Expr 

11= Expr V Expr 

ll« Expr Ebq?r 

11= 'K'Expr <*;Expr>*'>* 
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There are 3 categories of ejqwressions, namely, enum^ted, bitvector, and multidimen- 
sional expressions. Enumerated expressions are restricted to enumerations, Bitvector 
expressions can be an integer, value, bitvector variables, and bitwise, arithmetic, and 
concatenation operations over these variables, Bitvector expressions can be signed or 
unsigned. Integers are assumed to be signed, values are unsigned, and all bitvector 
variables are unsigned. Based upon their aiTgmnents, the arithmetic operators perform 
the appropriate signed or unsigned addition and negation- Both tiie bitwise and arith- 
metic operators result in a signed expression if either of their arguments is signed. The 
concatenation is assumed to be signed if the leftmost expression is signed. Multidi- 
mensional expressions can be multidimensional variables and bitwise operations over 
these variables. The operator - is the bitwise negation operator. The operators and 
(&), xor i^), or (I) are the bitwise binary operators. The bitwise binary operators 
require the two arguments to be of the same size except if the arguments arc bitvector 
expressions. Signed bitvector expressions are sign extended and unsigned bitvector 
ate zero-extended. The operators + and - are the arithmetic operators. Concatenation is 
a set of comma separated bitvector expressions enclosed within < and >. 

Index 

::= Expr 

IkErpr *:' Expr 

Indices have to be bitvector expressions. An index can be a single expression or two 
colon seperated expressions denoting a range. In the ZLSB notation, the first expres- 
sion should be greater than the second. In the ZMSB notation, the first expression 
should be less than the second. 

BoolExpr 

w-BoolTerm 

11= BoolTerm ' &&' BoolTem 
11= BoolTerm '11* BoolTerm 
BoolTerm 

::= X'BoolTermy 
\\= Expr Expr 
\\= Expr '1=' Expr 
\\=Expr V Expr 
\\=Expr^<* Bxpr 
\\=Ejq>r Expr 
11= Expr '<=' E^r 

The operators >, <, >=, <= are the relational operators- Relational operators operate on 
bitvector ^pressions. The relational operators can deal with both signed and unsigned 
bitvector expressions. The operators =, != arc the equality operators. Equality opera- 
tors operate on both enumerated, bitvector, and multidimensional expressions. 

Hie precedence and order of evaluation of the operators are the same as in the C pro- 
gramming language. The logical and bitwise negation operation have the highest pre- 
cedence and associate from right to left. All other operators associate &om the left to 
right. Next in order of decreasing precedence are the arithmetic operators followed by 
the relational operators followed by the equality operators. After that are the bitwise 
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opi?rators with &, I in decreasing precedence order. The logical operators are lowest 
in the precedence order with II having lower precedence than && . 

EXAMPLE 

Here is an example for a specificaiioo of an addressable accumulator. The specification can 
maintain the sum of signals for m diflferent channels, storing the sum in its register array. There 
are two possible operations. The store operation stores the value on the data input in the 
addressed register. The {idd operation takes the sum of the data input and the addressed register 
and stores it back in the addressed register. In this specification, the register array has 4 regis- 
ters with each register having 2 bits of data. The sizes have been defined with DEFINE state- 
ments diat get expanded in the preprocessing stage in SPG. 

/* 2 bits per word */ 
DEFINE DAIASIZEl 

ra = 4 words in the register file. */ 
DEE=INEREGSIZE3 
/* Addj^s Size = Log(REGSIZE> = 2 */ 
DEFINE ADDRSIZEl 
MACHINE accumulator; 

TYPE DAIAWORD IS ARRAY (DAEASIZE TO 0) OF BIT; 

TYPE ADDRWORD IS ARRAY (ADDRSIZE TO 0) OF BIT, 

TYPE OPS IS (store, add); 

STATE op: OPS; 

STATE address : ADDRWORD; 

STATE datain, dataOut : DATAWQRD; 

STATE register ; ARRAY (0 TO REGSIZE) OF DAIAWORD; 

Set Of Assertions ♦***/ 
StoreAssertLon { 

VARIABLE i : ADDRWORD; 

VARIABLE a : DAIAWORD; 

(op IS store) ANI> (dataLi IS a> AND (address IS 5) 
LEADSTO 

(dataOut IS a) AND (registerp] IS a) 

} 

AddAssertion { 

VARIABLE i : ADDRWORD; 
VARIABLE a, b : DATAWORD; 

(op IS add) AND (datain IS a) AND (address IS i) AND (register[il IS b) 

LEADSTO 
(dataOut IS a-t*) AND (reg;isterli} IS a+b) 

) 

MaintainStaceAssertion ( 

194 

PAGE259/277*RCVDAT7/18/20M7:43:08 PM (Eastern Daylight T^^ 



07/18/2005 17:33 FAI 408 720 9397 BST&Z ©280 



VARIABLE i, j : ADDRWORD; 
VARIABLE b : DATAWORD; 
WHEN(i !=j) 

(address IS i) AND (register|jl IS b) 
LEADSTO 

(register[fl IS b) 

} 

ENDMACHINE 

SOME FRAGILE EXTENSIONS OR SHORT FORMS 

An expression of the form 

'C Ej^tA ExprB ExprC 
can be used as a short form for 

'C ExprA '<• ExprB ')* ExprB EjqirC 

The expression 

(FboVar[23:26] ==» B"0-OJ") 
can be used as a short form for 

(FooVar[23J==0) && (FooVar[25:26]==B"0J " ) 

Note that this is a fragile extension. This extension for constants can just be used for equality 
opurators. For odier operators, die behavior is undefined. 

SEE ALSO 

spg(l) $te(l) tnap(5) ordcr(5) 

D- L. Beatty, "A Methodology for Formal Hardware Verification, with Application to Micro- 
pjTOoessors " PhD Thesis, Carnegie Mellon University, CMU-CS-93-190, August '93^ pp. 78- 
96- 

.BUGS AND LIMITATIONS 

Should we allow the ability to define signed bitvector variables? 

Have not defined the semantics when the state and expression in a clause have different sizes? 
A related question is what happens in an indexed expression if the index is out of range? 

The problem with expression indexing is that do we implicitly assume index 0 conesponds to 
be the first element? How do we resolve this with array variables where the from field is non- 
zeio? Also the other question should we allow range indexing for states? 

In expressions, si>ecifying a constant repeating pattern of the form: 

\UExpr'W Number 

AUTHOR 

Alc^ Jain, Carnegie Mellon University 
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Appendix B 



Implementation Mapping Language 



NAME 

MAP - format for the implementatjon mapping^ 

The implementation mapping provides a mapping between the high-level specification and a 
low-level realization. The high-level specification is described in the Hardware Specification 
Language, Iisl(S). The low-level realization can be described in the vlog(5) format. 

The Hardware SpeclficaUon Language consists of several interacting finite-state machine. 
Each machine is associated with a set of type definitions^ state variables and a set of assertions. 
The implementation mapping defines a m^>ping for each of these machines The mapping has 
relevance only in the context of an HSL description. So read the hsl(5) man page before going 
through this man page. 

DESCRIPTION 

Reserved keywofds for the mapping language are given below. 



ALIAS 


AND 


ARRAY 


AT 


Brr 


CASE 


COND 


ELSE 




ENDMACHINE 


ENTITY 


EVENT 


FROM 


INVALIDATE 


IS 


LEADSTO 


MACraNE 


MAP 


NEXT 


NEXTMARKER 


NODE 


OF 


PHASE 


RANGE 


STATE 


SYNCH 


TO 


TYPE 


VARIABLE 


VERTEX 


WHEN 





The lower case versions of these keywords are also reserved and can be used interchangeably. 

LEXICAL CONVENTIONS 

Vertical bar I indlcares choice. Question Mark ? follows optional items. Star * follows 
items that can be repeated 0 or more tin^. Plus + follows items that can be repeated 1 or 
more times, and parentheses < > indicate grouping. 

WhiteSpace ::= <SpaceChar>^ 
SpaceChar blank I tab I newline I carriage return- 
Comment ::= OneUneComment I BlockComment 
OneUneComment 

II any text opto newline 



197 



PA(£262/27PRCVDAT7H8/20W7:43:08PM[EastemOayIightm^^ 



07/18/2005 17:34 FAX 408 720 9397 



BST&Z 



@263 



BlockCotnnient 

/* any text string Uiat doesn't contain "+/" */ 
Id&nt 

Any sequence of letters, digits, dollar signs, and underscore symbols, except key- 
words. The first character has to be a letter or underscore symbol. Idents are case sen- 
sitive. 

IdentUst Ident <*; Ident>* 

A Jist of identifiers separated by commas. 

Escnpedldent ::= Ident Ident>* 

Escaped Indentifiers start with the backslash character and can include any printable 
ASCn character. Escaped Identifiers end with white space. 

Name Ident I Escapedldent 

Names are case sensitive. 
Integer 

An integer- 
Number 

Any non-negative integer. 

Value : := BinaryValue \ OctalValue 1 HexValue 

Values are enclosed within double quotes. A prefix character can be used to specify a 
binary (B). octal (O), or hexadecimal (X) value, as shown below. If a prefix character 
is not specified, then the value is assumed to be a binary value. 

Bmarymue B?«<Oll>+** 

In this notation, single bit values can be represented as B"0" or B"l". HSL permits 
^0' or '1' as alternative notations forfait values. 

OctalValue O"<0-7>+" 

HexValue X"<0-iMA-RH-» 

ORGANIZATION 

The m;ipping language contains exactly one Program^ as described by the following infor- 
mal BNR Terminal symbols are tendered in boldface and enclosed in single quotes. White 
space may be included between any items. 

Pwgram ::= <Machine>* 

HSL can describe sev^al interacting finite-state machines. MAP provides a mapping 
for each of tfiesc machines. 
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Machine ::= 

'MACHINE* Ident 

<TypeDefio* 

<Stat€Decl>* 

<NodeDed>* 

<AliasDefk>^ 

<MappingBlock>'^ 
'ENDMACHINE' 

The macliine name identifies a finite-state machine in the HSL description- The HSL 
description has a set of type definitions and state declarations associated with the 
machine. These type definitions and state declarations are assumed to be visihle and 
can be used in defining the mapping for this machine. The type definition and state 
declaration section in the mapping can be used to declare an additional set of types 
and stares. The node declarations declares a set of nodes for the machine. The ahas 
definitions define a name mapping from the nodes to actual net names in the realiza- 
tion. The main component of the mapping is in the mapping blocks. The mapping 
blocks define a temporal and spatial mapping from the set of state elements (strictly 
assignment to state elements) to the set of nodes (again strictly assignment to nodes). 

TYPE DEFINITIONS 

TypeDefn ::= 'TYPE' Ident 'IS* Types 

Type definitions give names to types. This makes it convenient to declare state and 
local variables by lefening to type names. 

Types 

*Brr' 

11== 'RANGE' Number 'TO' Number 

IM IdentUst 

\\=fdeni 

11= 'ABRAV *(' Number TO' Number y 'OF' Types 

Basic types include bit, subranges of fixed non-negative integers, and enumerations. 
Types can also be identifiers corresponding to type definitions and fixed sized arrays 
of these types. In airays ihe first number refers to the most significant bit and the sec- 
ond numbCT to the least significant bit The ZLSB (zero is least significant bit) nota- 
tion requires the first number to be greater than the second. The ZMSB (zero is most 
significant bit) notation requires the first number to be less than the second. Either 
notation can be used. However the same notation has to be used in all array declara- 
tions. The single bit tjfpe, integer range type, and single dimensional array of bit are 
collectively referred to as bitvector types, Enimierations and array of enumerations are 
referred to as enumwated types. Array of ranges and multidimensional arrays of bit 
are referred to as multidimensional types. 

SI ATE DECLARATIONS 

StateDecl 'STATE' IdentUst Types 

The state elements define the state space of the machine. The state elements can be 
classified into 3 categories based on their typc$, namely enumerated, bitvector, and 
multidimetisional states. Enumerated states are state elements of enumerated type. 
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Bit vector states are state elemcDts of bitvector type. The rest of the state elements aiie 
multidimcncisional states. 

NODE DECLARATIONS 

NodeDecl ::= 'NODE' Node <%' Node>* 

Node ::= Ident <*[' Number TO' Number 'J'>* 

The nocte declaratioD section defines a set of nodes, A node can be a single node or an 
aiTuy of nodes. In the ZLSB (zero is least significant bit) notation, the first number 
should be greater than the second In the ZMSB (zero is most significant bit) notation, 
the first number should be less than the second. A node either direcdy defines an 
actual net or can be aliased to a net in the realization. Array nodes have to be associ- 
ated with an alias definition to map them into actual net names. 

ALIAS DEFINITIONS 

AliasDefit ::= *ALIAS' NodeName ActualN^tName 

NodeNome Jden^'VfdenfY>'' 

ActualNetName < TNa7ne^Y<TExpr'Y>^>^ 

The alias definition can be used to map nodes into actual net names in the realization. 
Array nodes have to be associated with an alias definition. The node name identifies, a 
node from the set of node declarations. Airay nodes have to be associated with a set of 
disonct variables corresponding to node indices. These are implicit index variables 
whose size is picked automatically from the node declarations. The actual net name is 
a concatenation of names and expression indices. Expression indices are bitvector 
expressions over the implicit variables introduced in the node names. The implicit 
variables are local to the alias definition. 

As an example, assume the following node declaration and coiresponding alias defini- 
tion: 

NODE ram[l TO 2][0 TO 2); 
ALIAS ramplQ] {ram.}[i]{-}[2-jJ; 

In this example i and / are implicit variables. The nodes ram[ll[0], ram[l][l], 
rani[l}[2J, ram[2J[0], ram[2]Il] and ram[21[2} are getting mapped into actual nets 
ram.1.2, ram.l . J , ram.1,0, ram.2.2, ram.2.1 and ram.2*0 respectively, 

MAPPING BLOCKS 

Mc^pingBlock 
::= EntityBlock 
n^MapBlock 
\l=AppendBlock 
11= ImalidateBlock 

The mapping blocks provide a temporal and spatial mapping &om the set of state ele- 
ments (strictiy assignment to state elements) to the set of nodes (again stricdy assign- 
ment to nodes). The temporal aspect of the mapping alongwith the flow of control is 
defmed in tenns of "control graphs." The entities define a hierarchy of control grajAs 
which defines the temporal hierarchy for the realization. The upper most entity in the 
hierarchy (which we shall refer to as the "main" ratity) defines the flow of control for 
the assertions in the HSL, The map blocks define a mapping for an assignment to each 
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state element in the machine. The leoiporal aspect of the mapping is captured by a 
control graph in the map block which is related to the '*inain" control graph. The spa- 
tial aspect is captured by a set of labeDings on the control graph. The append block is 
used 10 add clauses to the assertion, which are specific for this realization. And finally 
the invalidate block is used to invalidate certain compositions of the control graphs. 

CONTROL GRAPH 

VertexDecl 'VERTEX' MentUst VertexTypes y 
VenexTypes 

*EVENT' 

Ik ^PHASE' 

{\=ldent 

The control graph has two type of vertices. The event vertices represent instantaneous 
time points. The state vertices represent durations of time. The basic state vertex type 
is a phase-level vertex. The state vertex type can also be an identifier corresponding to 
an entity. Entities have to be defined befoie tfaey can be used as vertex types- 

NextDefh :;= 
'NEXT' 
Edges 

'}• 

Edges 

w^ident'X* Idmt V 
W^Ident T IdenOAst T 

The next definition defines the edges in the control graph. Identifiers correspond to 
vertices declared in the vertex declaration section for this control graph. All vertices 
(except the sink vertex) should ^pear once and only once on the left hand side. A sin- 
gle edge can be defined from a vertex on the left-hand side to a vertex on the right 
hand side. Or a set of edges can be described from a single vertex to a set of vertices. 
The control graph should have a single unique vertex with no incoming edges. Tiiis 
venex serves as the source. Also, the control graph should have a single unique v^tex 
with no outgoing edges. This vertex sCTves as the sinlc 

ENTTTy BLOCKS 

EnlityBlock ::= 

^ENTITY' Idem *{' 
<Vert£xDecl>*^ 

NextDefh , 
<NejtMarkerFunctiaro7 \^ 
MapClauses 

Entities are used to describe a hi^archy of control graphs. The vertex declarations and 
the next definition define the control graph associated with the entity. Each miK;hine 
should have one (and only one) entity associated with the nexitnarkcr function. The 
entity with the neximarker function serves as the **main^ entity. The map clauses 
define a labelling on the state vertices in the control graph. 
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NextMarkerFunction ::= 
mXTMARKER' *{' 

Idenr *f MainEventVertex 

Tin? NextMarker function is defined on event vertices. The identifier on the left-hand 
side identifies an event vertex in this control graph. The main vertex is an event vertex 
in the "main" control graph, 

MainEventVertex ;:= ldent**ldent 

The firsi identifier corresponds to the name of the *'niain" entity. The second identifier 
identifies an event vertex in the ' Wdn" entity. 

MAP BLOCKS 

MapBlock 

'MAP' XStateClausey 'TO' 

NextDefii 
SynchFunction 
<LocalDect>^ 
MapClauses 

r 

11= 

'MAP' XStat^Clnusey *TO' *{' 
<VertexDect>* 
NextDefii 
SynchFunction 
<IjOcalDecl>* 

'COND' CondClause < 'AND' CondCiause >♦ 
MapClauses 

•r 

The map block provides a mapping for a state clause. A state clause coiresponds to an 
assignment to a state elemenL The vertex declarations and the next definition define 
the control graph associated with the map block- The synch fimction synchs the con- 
trol gr^ph to the "main" control graph. The map block can be associated with a set of 
local variables that are used in the map clauses. The map clauses defines a labelling on 
the state vertices in the control graph. The mapping for tliis state clause may be depen- 
dCTrt on other state clauses in the HSL. The cond clauses can be used to define state- 
dependent mappings. 

StateClause :\~StaieTerm *IS' Idem 

The staieterm identifies a unique state element in die HSL description. The identifier 
is a distinct variable. This is an implicit variable whose type is picked automatically 
from die state declaration in HSL. 
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StateTerm Jdent <'[7c/e/i?']'>* 

The stateterm is identifying a unique state in the HSL description. Array states can be 
associated with a set of distinct variables corresponding to array indices. These are 
implicit index variables whose type is picked automatically from the state declaration 
in HSL. The indexing level in the stateterm has to be equal to or deeper than the deep- 
est indexing level used in all the assertions for this machine. 

CondClause 

::= XStateClausey 

(1= XStateClause 'SYNCH' MainEventVertexJ 

The cond clause is used to define state-dependent mappings. It is used to bring in 
information about other states in the assertion. The cond clause is either a simple state 
clause or a state clause with synch information- The main vertex identifies an event 
vertex in the "main" control graph. And this synch informarion overrides the synch 
information in the map block for the state clause. 

SynchFunction 
'SYNCH' 

Ident MaxnEventVertex 

r 

The synch function is defined on event vertices. The identifier on the left-hand side 
identifies an event vertex in this control graph, Tlie main vertex is an event vertex in 
the "main" control graph. 

APPEND ASSERTION BLOCK 

AppendBlock ;:= 

'APPEND' Ident *{' 
<LocalDecl>* 
Clause <'AND' Claus€>* 

XEADSTO' 
Clause <*AND* Claus€>^ 

The identifier in the append block identifies an assertion block in the HSL. All local 
variables in the HSL assertion block are visible and can be used withm this block. 
Additional local variables can be declared. The clauses are appended to the HSL 
assertion block- 

Clause 

::= X y 

11= 'C Sme *IS' Expr y 
11= X *WHEN' XBoolEjpry Expr y 
\^ 'C State *IS' Expr *SYNCH' MainEventVertex 
11= r *WHEN' 'CBoolExpry Expr 'SYNCH* MainEventVertex y 
State ::=Ident<T£vry>^ 

Each clause in the append assertion is either empty, defines a simple assignment or a 
conditional assignment to state elements. The difference between clauses in HSL and 
MAP is that the clauses in the mapping can be associated with synch information. The 
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synch infomnation overrides the synch infoimatioii m ihe map block for the stale ele- 
ment 

INVALIDATE BLOCKS 

Irwalid/xteBlock ::= 
'INVALIDATE' 

< *C MapStateVertex<*; MapStateV€nex>+ y >^- 

r 

Restrict the composition so as to invalidate certain combination of state vertices in 
map blocks. 

MapStateVertex Idem': Idem 

The first identifier corresponds to a state element. The second identifier identifies a 
state vertex in the map block for the state element. 

MAP CLAUSES 

MapCIauses ::= MapClause < *AND' MapClause >^ 
MapOause 

LabelClause 

11= CaseCUmse 

11= WhenClause 

The map clause can be a leaf-level label, a case staten^t, or a when statemenL 
LabelClause 
•LABEL' {* 

Label < * AND* Label >* 

r 

Label 

::= 'C l^el y 

11= Ident <TExpry>* 'IS' Expr 'AT PfuiseVertex 

11= Ident <TExpry>* *IS' Expr 'FROM' PfmeVenex TO' FhaseVertex 

The label clause defines assigns expressions to nodes at particular time points in the 

control graph. The identifier is a node defined in the node declaration secticxi. Expres- 

sions are over the implicit and local variables defined in this block. Indices have to be 

bit vector expressions. The phase vertex is the full path name for a phase-level vertex 

in the control graph hierarchy. 

PhaseVertex ::= Ideni<\'Ident>* 

The phase vertex identifies a specific instance of a phase-level vertex- Hie first identi- 
fier is a state vertex in the control graph for this mapping. If the state vertex lype is an 
entity, then the second identifier is a stare vertex in fiie entity control graph. And so on. 
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WkenCUiuse 

'WHEN' TBoolExpry 
MapClauses 

r 

11= 

*WHEN' TBoolExpry *{' 

MapClauses 
*y 'ELSE' *{' 

MapClauses 

r 

Clauses can be associated with a Boolean restriction. The Boolean expression is over 
local and implicit variables in this block. 

CaseClause 

*CASE' TIdenty *{' 

<'IS' Eipr MapClauses 

r 

The case statement performs a multi-way branch on the variable based upon Che 
expressions. The case identifier is one of the implicit variables in this block. The case 
variable is limited to be an enumerated or bitvector variable. For an enumerated case 
variable^ the expressions are limited to be simple enumerations. For a bitvector case 
variable, the expressions are limited to be bitvector constants. 

LOCAL VARIAJBUES IN BLOCKS 

LocalDecl 'VARIABLE' IdentUst T^pes 

Both alias and map blocks can be associated with local variables. The types syntax is 
the same as in HSL and has been reproduced below. 

::= 'BIT' 

11= 'RANGE* Number 'TO* Nimber 

IdentListy 
W^Ident 

11= ^ARRAV X Number 'TO* Number 'OF' Types 

Basic types include bit, subranges of fixed non-npgative integers and enumerations. 
Types can also be jdendfiers corresponding to type definitions and fixed sized arrays 
of these types* In arrays the first number refers to Che most significant bit and the sec- 
ond number to the least significant bit. In the ZLSB notation, the first number should 
be greater than the second- In the ZMSB notadon, die fiist number should be less than 
the second. Identifi^ correspond to visible type definitions in HSL. The single bit 
type, integer range type, and single dimensional array of bits are collectively referred 
to as bitvector types. Enumerations aiKi array of enumerations are referred to as enu- 
merated types. Array of ranges and multidimensional array of bits are referred to as 
multidimensional types. 
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EXPRESSIONS 

The expression syntax and semantics is the same as in HSL. For the sake of completeness, 
it has been reproduced below. 

Expr 

Integer 
11= Value 

11= rdeni<'['Index'Y>^ 

11= Expr 

11= Ejq?r'&' Ejq?r 

I!= Ejq)r 1' Expr 

W^Expr Expr 

\\= Expr Expr 

11= Expr Ejpr 

11= '<'Expr <%'jExp/>**>' 

There are 3 categories of expressions, namely enumerated, bitvector, and multidimen- 
sioaal expressions Enumerated expressions are restricted to enumerations. Bitvector 
expressions can be an integer, value, bitvector variables, and bitwise, arithmetic, and 
concatenation operations over these variables, Bitvector expressions can be signed or 
unsigned. Integers are assumed to be signed, values are unsigned, and all bitvector 
variables are unsigned. Based upon their arguments, the arithmetic operators perform 
the appropriate signed or unsigned addition and negation. Bodi the bitwise and arith- 
medc operators result in a signed expressiCKi if eith^ of their arguments is signed. The 
concatenation is assumed to be signed if the left most expression is signed. Multidi- 
mensional expressions can be multidimensional variables and bitwise operations over 
these variables. The operator - is the bitwise negation operator. The operators^ and 
(&), xor C^), or (I) are the bitwise binary operators. The bitwise binary operators 
require the two arguments to be of the same si^e excq>t if tte arguments are bitvector 
expressions. Signed bitvector expressions are sign extended and unsigned bitvector 
are ssero-extended The operators + and - are the arithmedc operators. Concatenation is 
a set of conmia separated bitvector expressions enclosed within < and >. 

Index 

::=Expr 

11= Expr Expr 

Indices have to be bitvector expressions. An index can be a single expression or two 
colon seperated expressions denoting a range. In the ZLSB notation, the first expres- 
sion should be greater than the second. In the ZMSB notation, the first expression 
should be bss than the second. 

BoolE^pr 

::= BoolTerm 
11= BoolTerm 

BoolTerm *&&' BoolTerm 

BoolTerm "IV BoolTerm 
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BoolTerm 

::= XBoolTermy 
\\=Expr W £j^r 
\\=Expr'l=' Expr 
\\=E3cpr V Expr 
11= Expr Expr 
lis Expr '>=' Expr 
11= Expr '<=* E^r 

Tbe operators >, <, >=, <= are the relational operators. Relationa] operators operate on 
bitvector expressions. Hie relational operators can deal with both signed and unsigned 
bitvector esxpiessions. The operators =, !=; are the equality operators. Equality opera- 
tors operate on both enumerated, bitvector, aod multidimensional expressions. 

The precedence and order of evaluation of the operators are the same as in die C pro- 
gramming language. The logical and bitwise negation operation have the highest pre- 
cedence and associate from right to lefL AH other ojierators associate from the left to 
right Next in order of decreasing precedence are the arithmetic operators followed by 
the relational operators followed by the equality operators. After that are the bitwise 
operators with I in decreasing precedence order, Tbe logical operators are lowest 
in the precedence order with II having Jower precedence than && , 

EXAMPLE 

Here is an example of a mapping for a pipelined addressable accumulator. The corresponding 
specification is in the example section in h5l(S). The mapping is for a pipelined addressable 
accumulator circuit where the register access and adder operation occur simultaneously. A 
hold register has been incoiporated between the adder and register array. Bypass logic handles 
the case where the same address is used on consecutive operations. The mapping first defines a 
set of node declarations. Note that the DEFINE statements in tbe HSL are visible in the map- 
ping and can be used to define the size of tbe nodes. These will be expanded by a preprocessor 
in spg. The node declaration section is foUowed by a set of alias definitions which define how 
the node names are m^ped into actual net names in vlog. An endty is used to define the cycle- 
level vertex. The cycle consists of 4 non-overl^ping phases. The main entity defines flow of 
control. The flow of control has 3 cycles corresponding to the previous* current, and next 
instruction. The append block is used to define the address in the previous and next cycles. All 
the map blocks have a control graph with a single state vertex. These control graphs are 
synched with the cuiient cycle in the main control graph. The mapping for datain, address, 
and dcaaOut are simple leaf-level mappings. The mapping for op uses a case statement. Hie 
mx^it)g for the roister array is a complex one that defines the pipelining in the circuit If the 
cuiiently addressed abstract register is the same as the address in the previous cycle* then the 
efl'eciive data is in the hold register. Else the effective data is in the register array. 

MACHINE accumulator; 
NODE phil, phi2. Clear; 
NODE addr[ADDRSIZE TO 0]; 
NODE regLDREGSEZE TO OJtDATASIZE TO 0]; 
NODE regH[REGSIZE TO 0][DATASIZE TO 0]; 

NODE in[DATASIZE TO 0]. out(DATASIZE TO 0], holdPATASiZE TO 0]; 
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ALIAS addr[x] {\Addr. )[x]; 
ALIAS in[x] {Mn. 
ALIAS outW {\OuL }[x]; 
ALIAS boId[x] {\D$Hold-L. }[x]; 
ALL\SregL[x][y] {\D$Reg.L. }[x]{.}[yl; 
ALIAS regM[x][y] {\D$RegJI. )[xlf.}[y]; 

ENTITY cycle { 

A^RTEX psl, ps2, ps3, ps4: PHASE; 
VERTEX pel, pe2» pe3, p©4. pe5: EVENT; 
NEXT{ 

pel:psl; 

psl: pe2; 

pe2: ps2; 

ps2: pe3; 

pe3i ps3; 

ps3: pb4; 

pe4: ps4; 

ps4: pe5; 

} 

LABEL { 

(phil IS '0* AT psl) AND (phi2 IS '1' AT psl) AND 
(phil IS '0' AT ps2) AND (phi2 IS '0' AT ps2) AND 
(phil IS *r AT ps3) AND (phi2 IS '0' AT ps3) AND 
(pliil IS '0' AT ps4) AND (phi2 IS '0' AT ps4) 

} 

) 

ENTITY main { 

VERTKK csl, cs2, cs3: cycle; 
VERTEX eel, ce2, ce3, c©4: EVENT, 
NEXT{ 
eel: csl; 

csl: ce2; /* Previous cycle */ 
ce2: cs2; 

cs2: ce3; /* Cunent cycle */ 
ce3: cs3; 

cs3: cc4; t* Next cycle */ 

} 

NEXTMARKER {ce2: ce3;} 

} 

APPEND StoreAsseitiOd { 

VARIABLE u : ADDRWORD; 

(address IS u SYNCH main.ceS) LEADSTO Q 
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APPEND AddAssertion f 

VARIABLE k, u : ADDRWORD; 

(address IS k SYNCH maiQ.cel) AND (address IS u SYNCH main.ceS) 
LEADSTO 

0 

} 

APPEND MaintainStateAssertion { 
VARIABLE k, u : ADDRWORD; 

(address IS k SYNCH main,cel) AND (address IS u SYNCH maiii-ce3) 
LEADSTO 

0 

} 

MAP(opISo)TO{ 
VERTEX si: cycle; 
VERTEX el, e2: EVENT; 
NEXT { el: si; si: e2; } 
SYNCH {el: iiiain,ce2;} 
CASE(o){ 

IS store: LABEL {QearlS T ATsl.ps3} 

IS add: LABEL {Clear IS *0' AT sLps3) 

} 

} 

MAP(daiaInISd>TO{ 
VERTEX si: cycle; 
VERTEX el, e2: EVENT; 
NEXTf el:sl;sl:e2; } 
SYNCH {el: inain.ce2;l 
LABEL {mISdATsLps3} 

} 

. MAP (address IS v> TO (. 
VERTEX si: cycle; 
VERTEX el, e2: EVENT; 
NEXT {el: si; si: e2; } 
SYNCH {el : main.ce2; } 
LABEL {addr IS v AT sLpsS} 

} 

MAP (registerli] IS r) TO { 
VERTEX si: cycle; 
VERTEX el, e2: EVENT; 
NEXT { el: si; si: e2; } 
SYNCH {el:main.ce2;} 
COND (address IS k SYNCH niam.cel) { 

WHEN (i = k) { LABEL {hold IS ~r AT sl.ps2} } 

ELSE { LABEL { (regL[j] IS AT s 1 .ps3) AND (regH[i] IS r AT si .ps3) ) } 
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} 

} 

MAP (dataOut IS d) TO {| 
VERTEX si: cycle; 
VERTEX el, e2: EVENT; 
NEXT { el: si; si: e2; } 
SYNCH {el: main.ce2;} 
LABEL {out IS d AT sLpsl } 

) 

ENDMACHINE 

SOME FRAGILE EXTENSIONS OR SHORT FORM 

An expression of the fonn 

Ej^rA Ejq^rB E^rC *)* 
can be used as a short form for 

X' ExprA *<' ExprB y *(* E^rB ExprC y 

The expression 

(F0oVnr[23:26J ==B''0-02 ") . 
can be used as a short form for , 

(FooVhr[23J==0) &Sc (FooVarl25:26j==B"0r') 

Note that this is a fragile extension. This extension for constants can just be used for equality 
operators. For other operators, the behavior is undefined. 

SEE ALSO 

spg(l) Slc(l.) hsl(5) ortier(5) vlog(5) 

D. L. Beatcy, *'A Methodology for Formal Hardware Verification, wi^ Apphcation to Micro- 
processors," PhD Thesis, Carn&gie Mellon University, CMU'CS-93-t90, August '93, pp_ 163- 
174. 

HACKS 

All machine, state, numeration, and node names within a module have to be distinct. Some- 
times you wight want a state name to be same as the node name. In that case you can use the 
alias mechanism as follows: 

/* Assume state op is defined in HSL description for some machine. */ 
STATEop:BIT; 

/* Now assume you want to define a node Op for same machine */ 
NODE pseudo_op; // I>efine a node with some pseudo name. 
ALIAS psfiudo_op {op}; // Alias pseudo name into op| 
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BUGS 

HSL allows only a single 'Win" entity. That implies that all assertions hatvc to have a single 
flow of controL What do we do when we have multiple assertions with different flow of con- 
trol? 

I ajn not sure if the invalidate block should really be part of the mapping language. It seems to 
be a hack that can really be abused. 

HSL clauses for which a mapping is not defined are assumed to have a NULL mapping. 
Maybe MAP should explicitly specify a NULL mapping- 
Expression facility as in HSL is limited 

AUTHOR 

Alok Jain, Carnegie Mellon University 
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X. Related Proceedings Appendix: Covie^ of Decisi ons Rendered hv a Court or the 
Board in anv Prior and Pending Appeals. Interferences or Judicia l Proceedings 

There are no related appeals or interferences to appellant's knowledge that would 
have a bearing on any decision of the Board of Patent Appeals and Interferences. 
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